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Preface 


This volume contains the research workshops and doctoral symposium, as well as panel 
summaries presented at XP 2019, the 20th International Conference on Agile Software 
Development, held during May 21-25, 2019, at the Ecole de technologie supérieure in 
Montréal, Québec, Canada. 

XP is the premier agile software development conference combining research and 
practice. Whether you were new to agile or a seasoned agile practitioner, XP 2019 
provided an informal environment to network, share, and discover trends in agile for 
the next 20 years. 

Research papers and talks submissions were invited for the three XP 2019 research 
workshops, namely, Agile Transformation, Autonomous Teams, and Large Scale 
Agile. The workshops attracted a variety of agile software development topics related 
to the respective workshops. These included papers and presentations based on 
empirical studies and those conducted in industrial settings relevant to both researchers 
and practitioners. Submissions in various stages of progress were encouraged to gen- 
erate discussions at the workshops. The workshops were structured to include a 
combination of talks, including keynotes by researchers leading the field in the 
respective areas, a variety of research talks by new, emerging, and established 
researchers, and round-table discussion style sessions. Research agendas for the 
communities represented by the workshops were discussed, refined, and reported in the 
respective workshop summaries. 

The research workshops and doctoral symposium provide a highly relevant, 
friendly, and interactive platform to share and discuss emerging and late breaking 
research findings. They represent smaller, close communities of passionate emerging 
and established researchers and a psychologically safe environment to provide and 
receive feedback. 

The success of the XP 2019 research workshops and doctoral symposium was 
possible due to the contributions of the organizers, Program Committee members, 
authors, presenters, and general attendees. Last, but not least, I would like to express 
my sincere thanks to the XP conference Steering Committee and the Agile Alliance for 
their ongoing support. 

Panels at XP 20NN have been consistently among the best attended and 
well-received conference sessions following the conference plenary keynotes. This 
year’s topics included: Security and Privacy; The Impact of the Agile Manifesto on 
Culture, Education, and Software Practices; Business Agility — Agile’s Next Frontier; 
and “Agile — The Next 20 Years:” In the past we have published panel abstracts with 
panellist bios and position statements prior to the conference — however these abstracts 
did not reflect what was discussed at the conference. 

For XP 2019, we took a different approach. We prepared extended summaries of the 
panel discussions, which captured the panellists’ initial reflections on the panel topic, 
the principal questions from the floor, and panellist discussion. These summary articles 
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were forwarded to the panellists for review, and the reviewed summaries have been 
included in these post-conference proceedings. We hope that you find this content 
useful and relevant to both software research and industrial practice. 

Special thanks go to Dennis Mancl for his diligence in capturing and editing the 
panel conversations, the panellists for their participation and content review, and to the 
XP 2019 panel audiences for their questions and comments. 
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Abstract. Organisations are up-scaling their use of agile. Agile ways of 
working are used in larger projects and also in organisational units outside IT. 
This paper reports on the results of the first international workshop on agile 
transformation, which aimed to focus research on practice in a field which 
currently receives great attention. We report on participants’ definitions of agile 
transformation, summaries of experiences from such transformations, and the 
challenges that require research attention. 


Keywords: Agile - Transformation - Large-scale - Research agenda - 
Change management - Organisational change - Software engineering + 
Information systems 


1 Introduction 


In order to increase their ability to sense, respond and learn, organisations are up- 
scaling their use of agile. This implies that agile is used not only in larger projects and 
programs, but also in other organisational units outside of IT. In a foreword to the book 
“Unlocking Agility” [1], Bjarte Bogsnes writes: “The agile mindset is now finding its 
way into the C-suite, and it is starting to radically change the way organizations are 
led and managed. Business agility is on everybody's lips, for very good reasons”. 

While the implementation of agile methods traditionally has been studied at team level 
[2, 3], adopting agile practices across the organisation is widening this perspective and has 
been labelled “agile transformation”. Research has discussed three main areas of such 
transformations. First, challenges and success factors in the transformation process [4—10]; 
second, changes in roles and practices that occur during such transformations [11-13]; and 
third, models for understanding agile transformations [14, 15]. As an emerging research 
field, there are many understandings of what agile transformation is; also, current empirical 
studies tend to be descriptive and place little emphasis on theory to explain findings. This 
was the motivation to host the first international workshop on agile transformation in order 
to focus research on practice in a field which receives great attention. 

This paper summarises the workshop, which was conducted in half a day at the 
International Conference on Agile Software Development, XP 2019. The goal of the 
workshop was to challenge the scientific community to identify what should be of prime 
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interest to researchers in the area of agile transformations, as there are growing oppor- 
tunities to study them as companies increasingly adopt agile. Organisations are learning 
from agile practice to embrace agility in their ways of working; agile practitioners can also 
benefit from the wider context of organisations undergoing agile transformations, to 
understand their wider implications, and how to sustain them. The workshop received six 
submissions out of which four were selected for presentation. Maria Paasivaara was 
invited to give a keynote talk on tips for successful agile transformations. Following the 
presentations, participants offered definitions of agile transformation and discussed, in an 
open space format, the main research challenges in this area. 

The remainder of this paper reports the results of the workshop, and is structured as 
follows. Section 2 presents the definitions of large-scale agile transformation from par- 
ticipants. Section 3 provides an outline of the four presentations and of the keynote. 
Section 4 provides an overview of key research challenges identified by the participants at 
the workshop and at a similar workshop in London. Section 5 concludes the paper. 


2 What Is an Agile Transformation? 


For many organisations moving towards business agility is challenging as there are 
many elements at play, from culture and leadership to process and tools. The partici- 
pants in the workshop proposed different definitions for agile transformation as shown 
below; the terms ‘culture’, ‘reactive/responsiveness to change’ and ‘continuous 
improvement’ figured in several of them (Table 1). 


Table 1. Some of the definitions of agile transformation gathered at the workshop. 


“an individual’s, team’s, group’s and organisation’s journey into continuous improvements 
changing the way we do business, meet our goals and overcome our challenges by being 
more flexible, targeting smaller goals and providing continuous delivery, feedback and 
learning 

the process which evolves an organisation to be more reactive to changes in its environ- 
ment” 

“digital transformation -> agile becomes larger (programs, portfolios) and more important; 
also becomes more complex, needs alignment with other units that are not traditionally 
agile; change in leadership and management” 

“a people-centred approach to improving business outputs in the context of its environment 
the process undertaken to develop capabilities that will allow for flexibility in responding to 
a changing environment and continuous improvement” 

“a path from adopting agile practices to establishing agile culture” 

“transform from rather rigid structures, processes and hierarchy to a more network organi- 
sation with increased knowledge, understanding and collaboration across boundaries to 
improve a company’s reaction to external change in order to improve performance referring 
to effectiveness” 

“shift towards practices that enable organisational responsiveness” 

“agile — iterative, incremental, collaborative, effects/results/outcomes-driven transfor- 
mation — continuous improvement from where you are towards the Agile values and princi- 
ples” 
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3 Experience with Agile Transformation 


Lucas Green presented an industry case study of a big bang transformation with pro- 
cesses as usual having to coexist with new processes and resulting challenges; a 
research-based questionnaire was used to help understand team maturity during the 
transformation. A lesson from this case study is that the key to obtain understanding 
during the transformation is to support self-organising teams. 

Akim Berkani discussed agile transformation beyond IT based on a case study of a 
French administration department. His approach took a management innovation 
implementation lens (new structures, practices and processes) to explain the transfor- 
mation process. 

Johannes Berglind, Ludvig Lindlöf, Lars Trygg and Rashina Hoda presented a 
study of an agile transformation in the automotive industry; their study was conducted 
bottom-up with the engineers who already practiced agile informally before the top- 
down transformation was carried out. They highlighted the paradox of top-down 
transformations not taking into account the informal agile practices already in place. 
They suggested an approach that takes into account these informal agile practices 
already present incorporating them into the transformation. 

Katie Taylor took the lens of a practitioner business agility framework (www. 
agilebusiness.org) to identify the leadership elements needed for an agile transforma- 
tion. She proposed the analogy of ‘head, heart and hands’ therefore focusing on people 
and their central role in agile transformation. 

Maria Paasivaara gave the keynote at the workshop on tips for a successful agile 
transformation. They were based on past and ongoing studies of transformation pro- 
cesses in more than six private companies from sectors such as telecom and finance, 
and also from the public sector. The tips included ensuring management support, 
involving everyone in the organisation, communicating reasons for change, training 
everyone, hiring coaches with experience to help the transformation, ensuring trans- 
parency, developing an agile mindset, customising the transformation to fit organisa- 
tion and product, including effort to improve, focusing on systems thinking as well as 
physical workspace and infrastructure. 


4 Research Agenda on Main Challenges 


We carried out a survey with the workshop participants; the same survey had been 
carried out with the participants of a similar workshop targeted at industry that took 
place in London, UK, two weeks before. The total of 39 respondents were distributed 
as shown in Fig. 1, with the majority having management positions (35%), followed by 
research scientists (29%) and agile coaches (18%). The ‘Other’ group was composed of 
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E Team member 

E Agile coach 

E Project manager 
E Manager 

E Research scientist 
E Other 


Fig. 1. Roles of participants at the workshops who completed the survey. 


two consultants and one software architect. We do not claim that the respondents to this 
informal survey are in any way a representative sample of software companies or 
researchers in software engineering, but they are people interested enough in the topic 
to devote half a day to discuss it; they had an average of 6 years of experience with 
agile transformations (standard deviation: 6). 

Participants ranked their motivation for agile transformation after a scale taken from 
the state of agile survey’; the top three reasons were: ‘improve business/IT alignment’, 
‘enhance ability to managing changing priorities’ and ‘accelerate software delivery’. 

Participants were also asked to rank success factors and challenges slightly mod- 
ified from [4], based on own knowledge of transformation projects. They ranked the 
top three success factors to be: ‘changing organisational culture’, ‘leadership’ and 
‘engaging people’. 

Challenges were ranked as shown in Table 2. Participants could add ‘Other’ 
challenges to the list, which resulted in three more challenges: ‘shareholder value 
dominates operating models’, “competence-building and empowerment of teams’ and 
‘operations’. One respondent answered that the challenges available were ‘not good’. 

In both workshops, we discussed four of the main challenges and tried to identify 
relevant theory and research methods for future studies on these topics. More detailed 
minutes are available in a summary at the XP2019 programme website. 


' See VersionOne state of agile report: https://www.stateofagile.com. 
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Table 2. Ranked challenges in Agile Transformations, challenges taken from [4]. 


Challenge 


Hierarchical management and 
organizational boundaries 


Description 


Middle managers’ role in agile unclear 
Management in waterfall mode 
Keeping the old bureaucracy 

Internal silos kept 


Integrating non-development functions 


Other functions unwilling to change 
Challenges in adjusting to incremental 
delivery pace 

Challenges in adjusting product launch 
activities 

Rewarding model not teamwork centric 


Resistance to change 


General resistance to change 

Scepticism towards the new way of working 
Top down mandate creates resistance 
Management unwilling to change 


Coordination challenges in multi-team 
environment 


Interfacing between teams difficult 
Autonomous team model challenging 
Global distribution challenges 
Achieving technical consistency 


Agile difficult to implement 


Misunderstanding of agile concepts 
Lack of guidance from literature 
Agile customised poorly 

Reverting to old ways of working 
Excessive enthusiasm 


Lack of investment 


Lack of coaching 

Lack of training 

Too high workload 

Old commitments kept 

Challenges in rearranging physical work 
space 


Different approaches emerge in a multi- 
team environment 


Interpretation of agile differs between teams 
Using old and new approaches side by side 


Quality assurance challenges 


Accommodating non-functional testing 
Lack of automated testing 
Requirements ambiguity affects QA 


Requirements engineering challenges 


High-level requirements management 
largely missing in agile 

Requirement refinement challenging 
Creating and estimating user stories hard 
Gap between long and short term planning 
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5 Conclusion 


This workshop showed that the research community is interested in continuing studies 
on agile transformations, and that there is a growing body of studies on which to build 
up. We hope the initial research agenda developed at the workshop will inspire future 
studies. 
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Abstract. To succeed in complex environments and handle the innovation, 
development and support, organizations have to find ways to support and reg- 
ulate the autonomy of teams according to the environmental demands and 
limitations. Furthermore, there is no one-size-fits-all autonomy approach. The 
process of forming and implementing autonomous teams, as well as the effective 
functioning of such teams, is not yet adequately addressed and understood in the 
context of complex knowledge-intensive organizations. The second interna- 
tional workshop on autonomous teams investigated barriers for team autonomy: 
“What are the real-world problems to be solved for autonomous teams?” and 
“What concepts from the literature can be used to solve the problems?” 


Keywords: Autonomous teams - Agile - Team design - Coordination + 
Self-managing teams - Self-organizing teams 


1 Introduction 


Digitalization is changing the competitive landscape in many industries. A company 
conducting a digital transformation needs to (1) cultivate the leadership for such 
transformation, (2) develop an agile and scalable platform on which digital product and 
services can be delivered, (3) design new digitally enabled customer experiences, and 
(4) incubate and accelerate emerging digital innovations [1]. Handling these four 
capabilities at the same time is a complex task on many levels in an organization. 
Teams designing new digitally-enabled customer experiences and incubating and 
accelerating emerging digital innovations are challenged by increasingly complex 
problems that also involve external actors. For example, a design or development team 
needs to interact with many experts outside of their team and department [2], needs to 
rely on a number of technologies and work processes, and frequently makes decisions 
with economic consequences. High productivity, innovation, accuracy of problem 
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solving, and fast decision-making are handled best by autonomous teams [3—6] (also 
known as self-organizing or self-managing teams). 

Autonomous teams are described as teams given freedom by management [7] that 
take on the responsibilities of their supervisors [8], and are composed of people with a 
variety of skills to effectively tackle the variety in their external environments [9]. There 
is a high adoption rate of autonomous teams in many sectors, such as ICT, telecom, 
finance and banking, energy, transport and manufacturing. In the ICT industry, auton- 
omous teams are exemplified by extensive uptake of agile methods [10-12]. 

The process of forming and implementing teams with high autonomy, as well as the 
effective functioning of such teams, is not yet adequately addressed and understood in 
the context of complex team-based, knowledge-intensive organizations [5]. Moreover, 
research on teams has predominantly been based on cross-sectional survey data, often 
involving student teams, and has not sufficiently taken into account the complexity in 
which teams operate [5]. We argue that more research is needed on roles, management, 
leadership, authority, decision-making, learning, technology, and the role of such teams 
in networks of autonomous teams. We know so far that the emergence of informal self- 
organizing roles facilitates the transitions in team practices and management approa- 
ches in the process of becoming agile [13]. 


1.1 Roles in Autonomous Teams 


Traditional software development teams are comprised of formal functional roles such 
as developers, testers, and project managers. Agile methods (e.g., Scrum) replaced 
these with new formal roles (e.g., the Scrum master and product owner) that represent a 
cross-functional collection of old traditional (e.g. developers and testers), while also 
increasingly including other formal roles formerly beyond the core technical team 
boundary (e.g. the business analysts, user interface designers, and, more recently, 
artificial intelligence and machine learning experts). 

While the composition of the software development team became more diverse and 
inclusive, these new and expanded formal roles alone do not form the basis of 
autonomous teams. What makes a software development team autonomous is the 
presence of temporary and spontaneously emerging informal roles, such as mentor, 
coordinator, translator, champion, promoter, and terminator [10]. These roles focus on: 
(1) mentoring the new agile team into agile ways of working and autonomy, (2) co- 
ordinating with the customer on a regular and detailed basis, (3) translating between the 
business language used by the customer and the technical language employed by the 
team, (4) championing the cause of agile and autonomous teams with senior man- 
agement in case of bottom-up adoptions and championing agile transformation and 
autonomy with the teams in case of top-down adoptions, (5) promoting agility with the 
customer and educating the customer on his or her role and responsibility in supporting 
autonomous teams, and (6) terminating personnel not contributing positively to the 
agile ways of working and threatening the autonomous functioning of the team. 
Through the emergence of these roles, the team becomes self-organizing, with both the 
team and managers moving toward team-driven practices and empowering manage- 
ment approach respectively [13]. 
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2 The Workshop and Papers Presented 


The workshop included one keynote speech, “What makes your team self-organizing?” 
by Rashina Hoda from the University of Auckland. Further, the workshop had six 
presentations by researchers who had had their papers peer- reviewed. In a multiple- 
case study of three large organizations that implemented the Scaled Agile Framework 
(SAFe), Gustavsson [14] found that when several teams gather in joint events the teams 
get a better overview, higher feeling of autonomy, and the ability to stop planned work 
when it becomes too much. However, SAFe required the use of detailed plans and 
routines that somewhat reduced the team autonomy because the team members felt they 
had less mandate in choosing what to work on. In their study on large-scale agility in 
Bosch, Speigler et al. [15] found that low external autonomy limited team autonomy 
because of factors related to hierarchies, learning, structural dependencies, and rigid 
processes. They suggest companies need to foster learning organizations by providing 
time for communities of practice and open space meetings and tools to support 
transparency. Mikalsen et al. [16] relied on the Modern Sociotechnical Theory 
(MST) to understand team autonomy in a large, agile program with cross-functional 
BizDev teams. Their findings suggest organizations need to balance between agility 
and more standardized ways of working, and the de-bureaucratization ideal from MST 
is challenging to accomplish in complex organizations. Barriers for autonomy and 
efficiency included team members being dispersed, lack of team continuity, and use of 
shared resources. Petit [17] collected data, such as the quality of prior releases, to assess 
team autonomy from 70 teams in a bank. The teams were assessed using five levels of 
autonomy, and the effects of the assessment included teams governing each other as 
opposed to managers doing it, improved accountability of teams, reduction in time 
required for release approval, and reduced attempts to find workarounds and loopholes. 
Salameh and Bass [18] investigated how a large organization tailored agile practices to 
balance team autonomy and alignment. They reported on factors that promote the 
effectiveness of autonomous teams, such as informal and on-demand knowledge- 
sharing, collective code ownership, and the use of Lean Startup. Finally, Hukkelberg 
and Berntzen [19] reported on the challenges associated with integrating the data 
science role in agile autonomous teams, such as a lack of knowledge of the data science 
role (leading to sub-optimal use of the data scientist), the use of agile practices, and the 
lack of infrastructure. They suggested teams that want to expand with data scientist 
roles should arrange team kick-off, adjust their agile practices, use communities of 
practice, and provide training about the data science role and machine learning. 

In addition to the paper presentation there were two interactive sessions. In the first 
session, we collected feedback on team size for autonomous teams and the barriers for 
such teams using Mentimeter (a tool for receiving feedback from the participants). The 
second session was a group discussion on the real-world problems to be solved for 
autonomous teams and concepts from the literature that can be used to solve the 
problems. These real-world problems motivated a discussion that led to a research 
agenda. 
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3 Barriers for Autonomous Teams 


Mutual adjustment tends to be the primary coordination mechanism in autonomous 
teams. However, mutual adjustment in its pure form requires everyone to communicate 
with everyone. Therefore, the teams need to be dense, and since our communication 
abilities are limited that means they also have to be small. At the same time more and 
more teams are becoming BizDevOps teams (business, development, and operations in 
a team) to increase their authority, which often leads to large teams. We asked the 
workshop participants about the best team size for autonomous agile teams; 23% 
answered four to five members, 23% answered eight to nine members, and 54% 
answered six to seven members. 

The actual performance of an autonomous agile team depends not only on the 
competence of the team itself in managing and executing its work but also on the 
organizational context. In the 2018 workshop, barriers were identified [12]. During the 
2019 workshop, eight barriers for external autonomy were rated on a scale from 1 (not 
a barrier) to 10 (extreme barrier) (see Fig. 1). 


Not having clear 
and common goals 


Redefining the Lack of trust 
managers role 


Part-time = 3 ý Too many 
resources dependencies to 
others 
Too much stress Lack of coaching 
| and organizational 
support 


Right level of 
responsibility 


Fig. 1. Barriers for autonomous teams. 
4 Research Agenda 
Five areas of concern emerged at the workshop in 2018 [12] to help understand how 


companies can effectively enable autonomous agile teams: leadership, coordination, an 
organizational context supporting autonomy, design of autonomous agile teams, and 
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internal team processes. Each area suggested research questions that can be used to 
identify factors that increase, moderate, or limit the level of team autonomy, and the 
effects of autonomy on team performance were suggested. In this year’s workshop, the 
above-mentioned topics were prioritized. The rating was (1) coordination, (2) organi- 
zational context supporting autonomy, (3) leadership, (4) design of autonomous agile 
teams, and (5) internal team processes. 

In the last part of the workshop, the real-world problems that need to be solved 
were discussed (Table 1). Concepts from the literature that can be used to study these 
problems were suggested (e.g., Modern Sociotechnical Theory, Coordination Theory, 
Actor Network Theory, and the General Theory of Software Engineering). When 
investigating problems related to the personality of team members, theories like Big 
five and Myers Briggs were suggested. Other suggested areas of concern were 
onboarding, shared mental models, sourcing, team, and multiteam systems. 


Table 1. Real world problems to be solved. 


Area of focus Problem to be solved 

Complexity and roles Complex products and domains increase the need for large cross 
functional teams (e.g. BizDevOps). But smaller teams are more 
efficient than larger teams 


Distributed teams Distribution requires formation of virtual and remote teams. 
Creating virtual autonomous teams is a challenge. How to 
collaborate with outsourced teams 


Inter-team coordination Large projects and programs slow down the team. How can 
coordination be more efficient? How to balance the alignment of 
many teams vs. team autonomy? 


Organizational structure Autonomous teams need large networks but also work without 

too many interruptions. There is a problem building a network 

fast and maintaining the network and, at the same time, have time 
to do solve the team’s tasks 


Personality Personality can impact communication, coordination, and 
decision-making. However, you often have limited influence on 
who is on the team. What personality types or attributes foster 
autonomy? How to handle individual vs. team autonomy? 


Middle management and | Middle management need to support the teams and give the 
governance teams authority. What is the role of middle management, who 
decides what, and how do you balance management control vs. 
team autonomy? What legacy roles are needed? 


Team membership Stable teams is one key factor. However, teams grow and need 
new competence. Further, people want to change teams, projects 
and even companies. So how do you handle rotation and 
onboarding of new members? 


Define and measure The organization needs some control and feedback. However, the 
team should not collect data that is not used for the team to 
improve 
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Conclusion 


This paper gives an overview of what practitioners and researchers in the field of agile 
software development believe are emergent research themes for autonomous teams. 
Top-rated barriers for autonomous teams were (1) too many dependencies on others, 
(2) lack of trust, and (3) part-time resources. Further top-rated research topics for future 
research are coordination, organizational context supporting autonomy, and leadership. 


Acknowledgement. The Research Council of Norway partially supported this work through 
grant 267704. Additional support was provided by the following companies: Kantega, Knowit, 
Storebrand, and Sbanken. Thank you to the program committee members for thorough reviews 
and all the workshop participants for engaging discussions. 


References 


13. 


14. 


. Sia, S.K., Soh, C., Weill, P.: How DBS bank pursued a digital business strategy. MIS Q. 


Executive 15, 105-121 (2016) 


. Smite, D., Moe, N.B., Sablis, A., Wohlin, C.: Software teams and their knowledge networks 


in large-scale software development. Inf. Softw. Technol. 86, 71-86 (2017) 


. Cohen, S.G., Bailey, D.E.: What makes teams work: group effectiveness research from the 


shop floor to the executive suite. J. Manag. 23, 239-290 (1997) 


. Hoegl, M., Parboteeah, K.P.: Autonomy and teamwork in innovative projects. Hum. Resour. 


Manag. 45, 67-79 (2006) 


. Mathieu, J., Maynard, M.T., Rapp, T., Gilson, L.: Team effectiveness 1997-2007: a review 


of recent advancements and a glimpse into the future. J. Manag. 34, 410-476 (2008) 


. Hollenbeck, J.R., Beersma, B., Schouten, M.E.: Beyond team types and taxonomies: a 


dimensional scaling conceptualization for team description. Acad. Manag. Rev. 37, 82-106 
(2012) 


. Takeuchi, H., Nonaka, I.: The new product development game. Harv. Bus. Rev. 64, 137-146 


(1986) 


. Trist, E.: The evolution of socio-technical systems: a conceptual framework and an action 


research program. Ontario Quality of Working Life Centre (1981) 


. Morgan, G.: Images of Organizations. SAGE Publications, Thousand Oaks (2006) 
. Hoda, R., Noble, J., Marshall, S.: Self-organizing roles on agile software development 


teams. IEEE Trans. Softw. Eng. 39, 422-444 (2013) 


. Dingsoyr, T., Nerur, S., Balijepally, V., Moe, N.B.: A decade of agile methodologies: 


towards explaining agile software development. J. Syst. SW 85(6), 1213-1221 (2012) 


. Stray, V., Moe, N.B., Hoda, R.: Autonomous agile teams: challenges and future directions 


for research. In: Proceedings of the 19th International Conference on Agile Software 
Development: Companion, pp. 1-5. ACM, Porto (2018) 

Hoda, R., Noble, J.: Becoming agile: a grounded theory of agile transitions in practice. In: 
Proceedings of the 39th International Conference on Software Engineering (2017) 
Gustavsson, T.: Voices from the teams - impacts on autonomy in large-scale agile software 
development settings. In: Hoda, R. (ed.) XP 2019 Workshops. LNBIP, vol. 364, pp. 29-36. 
Springer, Cham (2019) 


15. 


16. 


17. 


18. 


19. 


Trends and Updated Research Agenda for Autonomous Agile Teams 19 


Spiegler, S.V., Heinecke, C., Wagner, S.: The influence of culture and structure on 
autonomous teams in established companies. In: Hoda, R. (ed.) XP 2019 Workshops. 
LNBIP, vol. 364, pp. 46-54. Springer, Cham (2019) 

Mikalsen, M., Næsje, M., Reime, E.A., Solem, A.: Agile autonomous teams in complex 
organizations. In: Hoda, R. (ed.) XP 2019 Workshops. LNBIP, vol. 364, pp. 55-63. 
Springer, Cham (2019) 

Petit, Y., Marnewick, C.: Earn your wings: a novel approach to deployment governance. In: 
Hoda, R. (ed.) XP 2019 Workshops. LNBIP, vol. 364, pp. 64-71. Springer, Cham (2019) 
Salameh, A., Bass, J.M.: Spotify tailoring for promoting effectiveness in cross-functional 
autonomous squads. In: Hoda, R. (ed.) XP 2019 Workshops. LNBIP, vol. 364, pp. 20-28. 
Springer, Cham (2019) 

Hukkelberg, I., Berntzen, M.: Exploring the challenges of integrating data science roles in 
agile autonomous teams. In: Hoda, R. (ed.) XP 2019 Workshops. LNBIP, vol. 364, pp. 37— 
45. Springer, Cham (2019) 


Open Access This chapter is licensed under the terms of the Creative Commons Attribution 4.0 
International License (http://creativecommons.org/licenses/by/4.0/), which permits use, sharing, 
adaptation, distribution and reproduction in any medium or format, as long as you give appro- 
priate credit to the original author(s) and the source, provide a link to the Creative Commons 
license and indicate if changes were made. 

The images or other third party material in this chapter are included in the chapter’s Creative 
Commons license, unless indicated otherwise in a credit line to the material. If material is not 
included in the chapter’s Creative Commons license and your intended use is not permitted by 
statutory regulation or exceeds the permitted use, you will need to obtain permission directly 
from the copyright holder. 


Check for 
updates 


Spotify Tailoring for Promoting 
Effectiveness in Cross-Functional 
Autonomous Squads 


Abdallah Salameh(®)@® and Julian M. Bass® 


University of Salford, 43 Crescent, Salford M5 4WT, UK 
{a.salameh, j.bass}@salford.ac.uk 


Abstract. Organisations tend to tailor agile methods to scale employed 
practices to have cross-functional autonomous teams while promoting 
sustainable creative and productive development at a constant pace. 
Thus, it is important to investigate how organisations tailor agile prac- 
tices to get the balance right between teams’ autonomy and alignment. 
Spotify model is originally introduced to facilitate the development of 
music streaming services in a very large-scale project with a Business- 
to-Consumer (B2C) model. However, developing a large-scale mission- 
critical project with a Business-to-Business (B2B) model is not essen- 
tially supported by the Spotify model. Thus, embracing Spotify model 
for such projects should be concerned about the question of how Spo- 
tify practices are adjusted to promote effectiveness of cross-functional 
autonomous squads in a mission-critical project with B2B model? 

In this paper, we conduct a longitudinal embedded case study, which 
lasted 21 months during which 14 semi-structured interviews were con- 
ducted. The Grounded Theory (GT) is adopted to analyse the collected 
data. As a result, we identify practices and processes that promote effec- 
tiveness in cross-functional autonomous squads, which have never been 
discussed in terms of Spotify model before. We also present “Spotify Tai- 
loring” by highlighting modified and newly introduced practices by the 
organisation in which the case study was conducted. 


Keywords: Spotify - Tailoring - Autonomous teams - 
Cross-functional - Large-scale agile - Offshore - Outsource - 
Mission-critical - Case study 


1 Introduction 


The introduction of agile development has shifted the focus from the individual 
level into the team level by employing self-organising teams that are autonomous 
but aligned [5,8]. To succeed in complex environments, software organisations 
should find ways to build their teams’ autonomy based on their environmental 
demands and limitations as there is no one size fits all autonomy approach [9]. In 
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fact, the topic of autonomous teams is immature within software engineering as 
there are challenges and future research directions that need to be addressed [9]. 

Spotify model is created around autonomous yet aligned squads [4]. It has 
been introduced for a very large-scale project with hundreds of developers over 
40 teams across 4 cities [4]. Due to the lack of scientific research on this model, 
there were no guidelines about how to build and maintain the alignment between 
the squads. In our previous work [8], we determined the influential factors on 
aligning Spotify squads in a large-scale project. In this paper, we aim to find 
how Spotify practices are adjusted to promote effectiveness of cross-functional 
autonomous squads in a mission-critical project with B2B model? 

We carry out a longitudinal embedded case study in a very large-scale 
organisation which has a large-scale offshore outsourced mission-critical software 
project. We conduct direct observation over 21 months and 14 semi-structured 
practitioner interviews to find out how organisations are actually tailoring agile 
practices to get the balance right between teams’ autonomy and alignment. 

We identify utilised practices and processes that promote effectiveness in 
cross-functional autonomous squads. This effectiveness is presented in the ability 
of aligning the Spotify squads which in turn enables squads’ autonomy. To the 
best of our knowledge, these practices and processes have not been identified 
before in terms of Spotify model. Due to the confidentiality agreement with the 
organisation, we do not provide a detailed description of the explored project. 


2 Spotify Model 


Spotify model, which is driven by creating cross-functional autonomous squads, 
is a result of tailoring Scrum and Lean methods to fit a very-large scale 
project [4,8]. Spotify squads are encouraged to use Lean Startup, which pro- 
mote innovation [4]. The overall structure consists of Squads, Chapters, Guilds 
and Tribes [4]. Squads have access to agile coaches who are in charge of improv- 
ing squads’ ways of working [4]. Also, each squad has a Product Owner (PO) who 
is responsible for (1) prioritising the work, (2) matching the product backlog, 
and (3) maintaining a high-level roadmap, which shows where the organisation 
is heading [4]. 

Squads’ autonomy is presented in the ability for minimising dependencies 
among them, bypassing layers of management, and acting upon internal decisions 
without relying on other squads [4,8]. To enable effective autonomy, the squads 
shall be aligned together [4]. Spotify creates alignment by employing an adap- 
tive structure, which is based on two dimensions, (1) vertical (i.e. Squads and 
Tribes) and (2) horizontal (i.e. Chapters and Guilds) [4]. Also, Spotify employs 
an alignment on the product-level to create expertise in specific areas [4]. In fact, 
previous research on Spotify model has identified influential factors on aligning 
Spotify squads by highlighting modified and newly introduced practices to the 
model [8]. This in turn indicates the necessity of expanding the alignment of the 
squads to cover further aspects based on the organisation’s needs. 

In Scrum-of-scrums, a synchronisation meeting is continuously conducted 
between the ambassadors of the teams to report completions, next steps and 
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impediments [6]. However, having inter-team meetings with only participants of 
similar interests is considered more beneficial [6]. In Spotify, a “squad-of-squads” 
meeting is conducted in which the leaders communicate what problems needs to 
be solved and why. The squads are expected to collaborate with each other to 
find the best solution. Since squads share products instead of owning them [4], 
collective code ownership is adopted implicitly [8]. A synchronisation meeting is 
conducted on demand to coordinate the involved squads [4]. Facing conflicted 
priorities between squads demands inter-team coordination [8]. Tackling such 
tasks, which have conflicted priorities, by other squads who lack expertise on 
the product-level demands a utilisation of peer code review between squads [4]. 

Spotify adopts a fail-friendly environment, which is not about who’s fault 
it is, but rather about capturing failures in a fast pace to learn and improve 
quickly [4]. Also, Spotify adopts Postmortem Documentation process, which is 
performed at the end of projects to determine what were successful or unsuccess- 
ful, to mitigate future risks [4]. Thereby, the organisation tends to improve the 
process and the product [4]. Furthermore, Spotify values cross-pollination more 
than standardisation as it causes less resistance. 

The employed release strategy in Spotify is based on enabling decoupled 
releases that simplifies the release process and encourages squads to provide 
small and frequent independent releases [4]. To achieve this strategy, Spotify 
employs a decoupled architecture [4]. To expose possible integration problems 
and to minimise the need for code branching, squads are allowed to release 
unfinished work as hidden by utilising toggle switch [4]. Each client application 
in Spotify has a release train that departs on its regular schedule [4]. A limited 
blast radius process is utilised through the delivery of small releases over a lim- 
ited number of end-users to do small experiments, prevent possible ripple effect, 
and to learn quickly instead of wasting time controlling all risks in advance [4]. 


3 Research Design and Methodology 


Our case study is carried out in a very large-scale organisation that employs 650 
staff members in 60 markets and processes around 60 billion EUR per year. The 
project, which is the scope of the case study, is considered as offshore outsourced 
mission-critical software project that manages autonomous financial services that 
operate under a common defined management policy. In this project, the devel- 
opment programme is of large-scale size [1] since developers are distributed over 
6 squads. There are also 1 architect, 3 key account managers (KAMs), 5 POs (2 
POs are empowered with KAM role), 2 agile coaches, and 1 test lead. 

Due to the lack of scientific research related to the Spotify model, this 
research draws on a longitudinal embedded case study |T] to investigate how 
organisations tailor agile practices and processes to get the balance right between 
squads’ autonomy and effective alignment among them. This research is com- 
prised of direct observation of around 225 ceremonies that last 21 months, and 14 
semi-structured interviews, which continued for around 50 min. After the second 
interview the questions were revised. Each interview was recorded and tran- 
scribed verbatim for detailed analysis in a continuous basis. 
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In this paper we employ the GT (Glasserian approach) to analyse the data. 
In essence, this is a process of continuous memoing, sorting, data collection, cod- 
ing, analysis and constant comparison, and theoretical saturation. Open coding 
process is used to break down the data analytically and generate categories and 
concepts. While conducting open coding process, a few questions, suggested by 
Glaser [2], were asked to facilitate the coding process. A constant comparison 
was used to refine the categories emerging from the identified concepts. Further- 
more, the observations were analysed and compared to the derived concepts from 
the analysed interviews. In result, minor contradictions were identified, which 
were explored and accommodated in the resulting grounded theory. 


Table 1. Spotify Tailoring for promoting effectiveness 


Category Adopted practices or processes Spotify Wake 
Study 
Adaptive Two dimensional structure Yes Yes 
structure Utilizing communities (Chapters and Squads) Yes Yes 
Utilizing communities (Guilds and Tribes) Yes No 
Collective code|Alignment over the product-level Yes Yes 
ownership Adopting a reconciliation process Unknown| Yes 
e Shared understanding of business objectives x Yes Yes 
Decision- — — - 
making Emphasising on shared decision-making x Yes Yes 
Utilising knowledge-based decision-making Unknown| Yes 
ern Formal inter-team coordination l No Yes 
ordia i On-demand inter-team coordination Yes Yes 
Informal inter-team coordination Unknown| Yes 
Peer code review between two squads Yes Yes 
Limited Fail-friendly environment No Yes 
Routine-meetings for squad-of-squads and demos| Yes Yes 
Knowledge z 
haning Chapter based knowledge sharing l Unknown| Yes 
Informal and on-demand knowledge sharing No Yes 
Postmortem Documentation Yes Yes 
Cross-pollination results in standardisation Yes Yes 
Mission based |Innovation based missions embrace Lean Startup| ~Yes Yes 
planning PL based missions embrace standardisation No Yes 
Decoupled releases via decoupled architecture Yes Yes 
Unfinished work shall not be released as hidden No Yes 
Release : 
strategy Backward compatible releases l No Yes 
f Release trains (features with toggle switch) Yes Yes 
On-demand releases Unknown| Yes 
Limited Blast Radius Yes Yes 


xYes: partially covered, Yes: covered, No: not covered, Unknown: no evidence 
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4 Findings 


In this section, we describe 3 emerged categories, which support the theory 
of balancing squads’ autonomy and alignment to promote the effectiveness of 
autonomous squads, by describing only newly introduced and scaled practices. 
These practices, which are the main focus of this paper, are presented in grey in 
Table 1. The rest of practices and processes are highlighted on in Sect. 5. 


4.1 Knowledge Sharing 


Limited Fail-Friendly Environment. Spotify adopts a fail-friendly environ- 
ment, which embraces fast failures to learn and improve quickly. However, the 
organisation in question utilises a limited fail-friendly environment as it pro- 
vides mission-critical software service. “As we provide software financial ser- 
vices, failure is not tolerated”—P1, Agile Coach and Architect. However, failures 
are inevitable during the pilot launch of new features, which aims to improve 
and verify the behaviour of new features. When a failure is encountered, “the 
responsible squad decides whether to switch off the targeted feature or to roll- 
back the release to overcome encountered issues”—-P7, PO and KAM. This in 
turn preserves squads’ autonomy as only the responsible squad is involved in 
investigating the problem. Also, The organisation employs these introduced fail- 
ures to embrace the learning and improvement for both of the process and the 
product. “We share the reasons behind encountered release issues in our squad- 
of-squads weekly meeting to improve the product and the process if needed”—P 12, 
PO. 


Chapter Based Knowledge Sharing. Spotify employs the communities of 
chapters, which represent the glue that sticks the whole organisation together, to 
establish cross-functional autonomous squads that are aligned together. In these 
chapters, members meet to help in solving problems within their competency 
areas. However, it is unknown if Spotify emphasises on the continuous sharing 
of knowledge within chapters. In the organisation in question, “sessions are 
conducted to share knowledge and expertise within our chapters... At the end 
of each session, we plan for the next one”—P8, Senior Developer. This in turn 
improves squads’ abilities and strengthens their autonomy. 


Informal and On-Demand Knowledge Sharing. While the software devel- 
opment programme in Spotify is of very-large scale (>300), the development 
programme in this organisation is of large-scale (<100). “We do not benefit from 
Guilds and Tribes as the development programme size is smaller than Spotify’s”— 
P6, PO and KAM. Thus, guilds and tribes are not applicable for this project. 
Therefore, “we call for meetings through Slack or email to discuss subjects of 
interest... Those who are interested can join”—P10, PO. This in turn strengthens 
knowledge sharing while preserving squads’ autonomy. 
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4.2 Mission Based Planning 


The squads respond to customers’ needs at different velocities based on their 
missions and scaled agile methods. While some missions value innovation more 
than plan fulfilment, others value plan fulfilment more than innovation. 


Innovation Based Missions Embrace Lean Startup. Spotify encourages 
the utilisation of Lean Startup to promote innovation, likewise the organisa- 
tion in question. Tasks of maintenance nature (i.e., adaptive or perfective) 
and/or of newly requested features are characterised with high degree of uncer- 
tainty. “Developing new features and adapting or improving already existed ones 
impose challenges due to the high-level of uncertainty... providing dynamic and 
generic solutions increase the complexity”—P9, Senior Developer. Such tasks 
require innovation to provide customers with business values. Hence, those 
squads tackling such tasks have missions that embrace Lean Startup princi- 
ples. “We have hybrid process based on Lean Startup and Kanban’—P10, PO. 
Software development estimation is considered as a waste. “We sacrifice the 
predictability of delivery to provide valuable features”—P6, PO and KAM. How- 
ever, “customers request sometimes an estimation before starting the develop- 
ment... We provide a rough estimation and keep the them involved”—P12, PO. 


Product-Line (PL) Based Missions Embrace Automation and Stan- 
dardisation (Plan Fulfilment). Since the project under study manages 
autonomous financial services, a PL architecture is utilised to streamline the 
process of integrating the project into external sub-systems. PL based missions 
embrace a “waste repellent culture” (aka Eliminating Waste in Lean Thinking). 
This is depicted through the utilisation of predefined checklists to automate 
software development. “We employ checklists in our PL to speed up the pro- 
cess and to cover the activities of planning, estimation, documentation, code 
review, and knowledge sharing”—P5, PO. This automation in turn strengthens 
squads’ autonomy and alignment. PL related tasks are characterised with low 
degree of uncertainty since “sufficient documentations are received to integrate 
to the targeted APIs”—P2, Senior Developer. Since the uncertainty is low and 
the requirements are matured, a planning process is employed to predict the 
delivery. “up-front planning and estimation processes are employed in our PL by 
utilising predefined checklists, bucket size, on-demand planning techniques, and 
Lead/cycle time”—P5, PO. Hence, POs can communicate the delivery deadlines 
with the customers. 


4.3 Release Strategy 


Unfinished Work Shall Not Be Released as Hidden. Spotify releases 
hidden features that are not 100% done. However, the organisation in question 
does not release unfinished features despite providing all new features with toggle 
on/off switch, which allows either hiding or exposing new features. This is to 
make sure (1) having clean code base to prevent possible inconsistencies between 
the squads while collective code ownership is adopted, and (2) having stable 
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features at production as the organisation provides a mission-critical services. “It 
is crucial to have clean code base that only has stable working features as the code 
is shared by all squads”—P1, Agile Coach and Architect. 


Backward Compatible Releases. The organisation utilises configuration- 
driven development to control the behaviour of the software application, mod- 
ules, or features at the execution time through configuration files. These files 
are used to (1) force certain business rules, (2) increase the software process- 
ing speed, (3) define interconnections between software components to make a 
compatibility, and (4) ease the development of correct distributed applications. 
Thus, the organisation provides backward compatible releases to prevent any 
deviation in the behaviour of the software service from the intended one in the 
old releases and to strengthen squads’ autonomy. “We always make sure that old 
features, components, and integrated APIs as well as their old configuration files 
working as expected... This is to satisfy customers’ needs and to prevent possi- 
ble conflicts of interests between the squads”—P4, Senior Developer. Also, having 
backward compatible releases is powerful to facilitate the process of rolling back 
a release in case of encountering issues. “New deployed releases shall be always 
backward compatible to be able to rollback in case of encountering issues”—P8, 
Senior Developer. 


On-Demand Releases. Since a decoupled architecture is employed in Spotify, 
a release train is established for each part of the software. Likewise for the 
organisation in question. “We utilise a decoupled architecture to (1) facilitate 
the alignment of squads on the product-level, (2) mitigate possible dependencies 
between squads, and (3) prevent impacting the whole system when a mistake is 
introduced”—P9, Senior Developer. However, it is unknown if Spotify facilitates 
providing on-demand releases in case of missing a release train. The organisation 
in question “employs DevOps to automate the process of release delivery”—P4, 
Agile Coach and Architect. Also, the organisation employs DevOps to facilitate 
on-demand releases in case of encountering a situation where a squad missed 
a release train. “If we missed a release train this week, we can either wait for 
the neat train or we can deliver the finished work whenever is demanded by a 
customer”—P7, PO and KAM. This in turn increases the autonomy of the squads. 


5 Discussion and Conclusion 


To maximise success in software development, organisations tend to tailor agile 
methods to best fit their needs. One of the important reasons for the organisa- 
tion under discussion to get transformed from Lean into the Spotify model is 
the need for loosely coupled, yet aligned squads while adopting different agile 
methods. Spotify has scaled agile software development to attain better perfor- 
mance, productivity and innovation [4]. Since squads’ autonomy is a key driver to 
enable the aforementioned attributes [9], Spotify focuses on enabling autonomous 
squads [4]. In fact, a common ground through maximising customer value was 
found since the organisation was adopting Lean whilst the Spotify model encour- 
ages the implementation of Lean Startup, which promote innovation. 
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To investigate how organisations tailor agile practices to get the balance 
right between squads’ autonomy and alignment, we conducted a longitudinal 
embedded case study in an offshore outsourced mission-critical project of large- 
scale. The case study lasted, so far, 21 months during which 14 semi-structured 
interviews were conducted. The GT was adopted to analyse the collected data. 

Based on the analysis of the collected data, a synergy has been discovered 
between (1) the identified practices by this case study, and (2) promoting effec- 
tiveness in autonomous squads. This effectiveness is presented in the ability of 
establishing the right balance between squads’ autonomy and alignment. Squads’ 
autonomy and alignment are interdependent and can have an inverse relation- 
ship. Too much alignment might hinder squads’ autonomy, but at the same time 
without alignment the squads can be autonomous yet not effective. Since self- 
organising teams are at the heart of Agile software development, teams must have 
common focus, mutual trust and respect, as well as accountability to organise 
themselves to meet new challenges [3]. 

Table1 presents these practices and processes, which are classified into 7 
categories. The first 4 categories in the table have been highlighted as influen- 
tial factors on the alignment of Spotify squads [8]. These influential factors are 
only a subset of practices and processes that contributes to the effectiveness of 
autonomous squads. The last 3 categories in the table present the new emerged 
practices and processes, which are the main focus of this paper. Modified and 
newly introduced practices and processes are presented in grey in Table 1, which 
are discussed in Sect. 4, whereas the rest are already covered in the literature [4]. 
The table also indicates the coverage of the adopted practices and processes by 
the Spotify model and the organisation. Moreover, the table clarifies the extent of 
which Spotify model has been scaled in the organisation (i.e., Spotify Tailoring). 

As for future work, we intend to determine employed product development 
practices in the context of scaled Spotify model for a global B2B model and 
investigate how these product development practices are correlated with the 
presented practices in Table 1. 
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Abstract. Forming autonomous, self-organizing, cross-functional teams in 
software development is becoming more common even in larger organizations, 
and many organizations are implementing the Scaled Agile Framework. When 
autonomous teams need to work together, they must sacrifice some level of 
autonomy since work needs to be coordinated with other teams, which could be 
a threat to team performance. This study presents how perceived autonomy has 
changed by listening to the voices from the teams in three large organizations. 
Although several respondents did not express any experienced changes to 
autonomy at all, others put forth important changes. The practices where several 
teams gather in joint events are important arenas in both positive and negative 
aspects. The arenas give teams a better overview and a sense of being 
empowered in using their veto right to stop overload of planned work. However, 
more detailed planning in every single team could cause less ability to switch 
work between teams and a sense of suffocation due to detailed routines and 
practices. 


Keywords: Autonomous teams - Self-organizing teams - Large-scale - 
Agile software development - Scaled Agile Framework 


1 Introduction 


Adopting agile ways of working and empowering autonomous, self-organizing teams 
in large-scale settings is becoming increasingly popular, and many organizations 
implement large-scale agile frameworks for software development [1]. When self- 
organizing teams need to work together, they must sacrifice some level of autonomy 
[2]. Design and programming need to be coordinated with other teams, and develop- 
ment efforts are often part of a portfolio or a program. According to Bass and Haxby 
[2], this means, for example, that self-organizing teams must sacrifice some creativity 
and autonomy to reach consensus on common standards. Reduced autonomy and 
creativity could lead to lower team performance, but the performance of an autonomous 
team does not only depend on the competence of the agile team itself; it also depends 
on the organizational context provided by management [3]. 

Also, most studies report positive impacts due to the empowerment of teams but 
some highlight potential challenges as difficulties in implementing autonomous teams 
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in certain settings or without sufficient leadership and support [4]. In the context of 
large-scale agile software development settings, there is a need for further research on 
the process of designing, supporting, and coaching autonomous agile teams to increase 
their performance. As highlighted in the proposed research agenda for autonomous 
teams at XP2018 [5], we need to get a better understanding of and deepen the 
knowledge about practices and strategies in forming autonomous teams. This will yield 
practical importance on how companies should organize for the right level of team 
autonomy and utilize autonomous agile teams in order to attain better performance, 
productivity, innovation, and value creation to strengthen competitiveness [5]. 

Some organizations, such as Ericsson [6], invent and tailor practices to scale up the 
agile ways of working while others implement full frameworks. The most commonly 
adopted framework today for large-scale agile ways of working is the Scaled Agile 
Framework (SAFe), according to the industrial survey The State of Agile [1]. Authors 
of SAFe, Leffingwell et al. [7], make a number of claims regarding expected benefits by 
implementing SAFe based on case studies written by end users. The highlighted 
benefits include, for example, increased team performance and more motivated 
employees. But these claimed benefits of SAFe do not stand unchallenged. For 
example, Schwaber [8], one of the originators of Scrum, criticize SAFe in several ways 
as being too top-down and inflexible, with the risk of suffocating teams under detailed 
routines and practices. This risk is verified by Conboy and Carroll [9] who investigated 
thirteen agile transformations and put forth that a major challenge was not to impose 
too many restrictions and rigidity when implementing a large-scale agile framework. 

The purpose of this study is to increase our knowledge about team members 
perceptions from working according to SAFe; to understand how autonomy has 
changed since the implementation of the framework. The research question for this 
study is: How is team autonomy affected by implementing the SAFe framework when 
agile software development is scaled up in the organization? Instead of hearing 
opinions from method makers, let us hear the voices from the teams. 

Three case organizations were investigated: Auto, a product development depart- 
ment within the Automotive industry. Gov, a project at a Government Agency in 
Sweden, and Bank, a development department in one of the four largest business banks 
in Sweden. The study of these case organizations began at the starting point of the 
implementation of SAFe, and interviews and observations went on for one and a half 
year. A survey was conducted about a year after the implementation began at the three 
organizations. 


2 SAFe 


SAFe consists of several roles, artifacts, practices, and routines described on different 
levels, starting from team level to the portfolio level, program level, and organizational 
level [10]. A very central practice is the joint planning two-day workshop with several 
teams for one Program Increment (PI) at a time, called PI planning. The practice, as 
described in SAFe [10], is aimed at dividing work and identifying dependencies 
between teams for a set period of time into the future; “PIs are typically 8—12 weeks 
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long. The most common pattern for a PI is four development Iterations, followed by 
one Innovation and Planning (IP) Iteration” [10]. 

Besides PlI-planning, there are other practices and routines such as Scrum of 
Scrums (SoS) where Scrum Masters from all teams frequently gather in short meetings 
to solve emerging dependency issues and System demo where several teams present 
results at the end of a sprint in a joint presentation event. As can be seen, practices and 
routines on the team level in SAFe propose several joint events between all teams 
working together. The artifacts, such as the Program board, are supporting tools to 
visualize the dependencies and the sequence of work. 


3 Method 


This is a multiple-case study where qualitative data is used to reveal how autonomy in 
teams is affected by implementing a large-scale agile framework. A survey was per- 
formed, and interviews were conducted. For further triangulation of data, several on- 
site visits were performed (see Table 1). 


Table 1. Data sources. 
Case Survey # of team Interviews | # of on-site Hours of 
responses members visits observation 
Auto 109 80 9 6 196 
Gov 56 39 4 5 113 
Bank 36 31 5 6 70 
Total: | 201 150 18 17 379 


The three studied organizations had implemented agile ways of working for three to 
five years with self-organized autonomous teams working side by side before they 
started investigating large-scale frameworks. All three organizations decided to adopt 
practices to be able to scale up and cooperate more efficiently between teams and 
started implementing SAFe during the beginning of 2017. Auto was first, starting in 
January while Gov began in March and Bank in April. The development organizations 
are divided into a number of teams with one Scrum Master (SM) per team and almost 
one Product Owner (PO) per team (some act as POs for two teams). 

Auto is a product development department in an organization within the automotive 
industry which mainly develops software but to some extent hardware (20% of all 
development) as well. The observed department, when the survey was conducted, was 
organized in 24 cross-functional teams, divided into three different value streams or 
Agile Release Trains (ART) to use SAFe terminology [4]. The total amount of people 
working in the department was 141. The average age in the department was 36,9 years 
old, with an average of 9,5 years working at Auto. 

The Gov-project is a SAFe implementation that started as a pilot project in a large 
Swedish Government Agency where large-scale agile processes were implemented 
with the aim of finding best practices to be used for the whole organization. Gov 
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consists of seven teams working in one ART. The total amount of employees in this 
software development organization was 70 people. The average age at Gov was 44,9 
years, with an average of 10,5 years working at Gov. 

Bank is a department in one of the major business banks in Sweden consisting of 
seven teams that work together in one ART. They decided to implement large-scale 
agile practices because a new software platform was being developed, which would 
increase the number of dependencies between all teams in the department. The 
department consists of 7 teams with 42 team members. Bank is also organized as one 
ART in the same manner as Auto and Gov. The average age in the department was 38,9 
years with an average of 9,6 years working at Bank. 

Regarding the survey, paper-based questionnaires were used at all organizations. 
They were handed out and collected during planning workshops when all teams par- 
ticipated. The survey was conducted in February 2018 for Auto, in March 2018 for 
Gov and in April 2018 for Bank. The questionnaire consisted of multiple sections: 
(1) background (e.g., the number of years worked in the organization), (2) agile roles, 
team, and department, (3) opinions of working in a large-scale agile context and effects 
on teamwork. This study focus on Sects. 3 and 2 was used to identify which respon- 
dents who were team members. Section 3 consisted of a number of multi-choice 
questions targeting the different practices in SAFe (that will not be used in this study) 
and the following two open questions: 


(1) “What do you consider as the main benefit of working according to SAFe in your 
organization?” 

(2) “What do you consider as the main drawback of working according to SAFe in 
your organization?” 


201 survey responses could be used: 109 from Auto, 56 from Gov and 36 from 
Bank, which represents a 79,4% (201/253) response rate. 150 of these responses came 
from team members (80 from Auto, 39 from Gov and 31 from Bank). 

The open-ended answers were first inductively coded, and themes were created 
based on expressed benefits and drawbacks. Then, all responses were analyzed 
deductively, searching for opinions related to team autonomy specifically. These 
opinions related to team autonomy are used in this study. 

To get a richer description, semi-structured interviews were conducted with 14 
team members and 4 scrum masters. The interviews contained a number of questions 
regarding large-scale agile work, and one of them was the following specific question: 
In what way has autonomy changed in the teams since the implementation of SAFe? 

Besides analyzing the answers from this question, the rest of the transcribed 
interviews were also read through in search of answers relating to team autonomy. 

Also, a total of 17 on-site observations were conducted (379 h of observation) 
during PI planning workshops, from April 2017 until November 2018, a period of one 
and a half years. Besides the performed interviews and use of the questionnaire, these 
on-site visits gave an opportunity to informal discussions and listening in on presen- 
tations and meetings which all benefitted to a better understanding. 

Thematic analysis, which is a qualitative inductive research approach [11], was 
conducted to analyze the transcribed interviews as well as the open-ended answers. The 
six-step analysis process [11] resulted in four major themes. 
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4 Results 


From the answers to the open-ended question in the survey questionnaire regarding benefits 
of working according to SAFe, 23 were related to autonomy in teams. Two of these answers 
spoke of autonomy but were not part of any of the themes. Instead, they addressed the 
benefits of being autonomous: “team autonomy gives motivation”, and “more fun and 
creative’. The remaining 21 answers were grouped into the four major themes. 

In 12 out of the 18 interviews conducted with 14 team members and 4 scrum 
masters the first, immediate, answer to the question: “In what way has autonomy 
changed in the teams since the implementation of SAFe?” was that it had not changed 
at all. But by going through the rest of the transcribed interviews, several answers 
regarding team autonomy could be identified. In the rest of this section, the four major 
themes based on both interview answers and open-ended questions, are presented. 


4.1 Veto Power 


An area where autonomy for the teams has improved, according to two of the 
respondents, is that it was easier to say no to more work now. Since the more detailed 
planning shows both available resources as well as “load” (the amount of estimated 
work each team has planned for), it was easy to see when there was too much of 
planned work. Both these respondents argued that, although this could have been done 
before the implementation of SAFe, it was easier now when everybody planned at the 
same time, in a joint workshop where differences between team loads became apparent. 

From the open-ended questions, the answer “it feels easier to reject/accept tasks” 
also speaks of a sense of improved veto power for the team. 


4.2 Give Help, Get Help 


Another area highlighted by a respondent was that it had become easier to help other 
teams. The team member expressed that previously, when teams had a dependency 
with another team and the other team was delayed, they often just sat and waited. Now, 
because of the joint planning, the team knew more about the intended feature, and it 
was therefore easy (and fun) to walk over to the other team and help them. 

The answer from the open-ended questions: “problems and success is shared and 
highlighted’ shows that the single autonomous team are perceiving a heightened 
decision-making power in both giving, and getting, more help. 

Likewise, five other answers to the open-ended questions put forth better possi- 
bilities for giving, and getting, help: “better coordination between and within team”, 
“resource allocation is planned and reviewed/confirmed independently”, “includes 
everyone in the planning”, “visualization within the team”, and “we can see what the 
other people in the teams are doing”. 

Three answers related to improved competence, which makes it easier to help out, 
both within the team as well as other teams: “Adds to a broadening of our compe- 
tencies”, “Broader competence” and “broadening our expertise’. Regarding compe- 
tence to, four answers displayed the need for help because of the challenges in putting 
teams together: “we are a team on paper but we can’t have common goals since we 
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have different distinct competencies”, “to get the right people in the right places”, “you 
are in a team where you don’t have common tasks to solve”, and “should have more 
mixed competencies in the teams”. 


4.3 Less Choice of Work 


Some respondents expressed the lack of freedom regarding choosing features to build 
for the team. Their explanation for this was the increased amount of planning, pre- 
planning, and refinement before each PI planning event. One of them, a scrum master, 
talked about the idea in SAFe that teams should be able to pick the features they want 
from the product backlog but that this was not possible in their organization. She 
reflected that it was not due to the specializations of the teams, but that pre-planning 
ahead of the PI planning event meant that product owners and stakeholders needed to 
discuss details with teams in advance and therefore, features naturally were dedicated 
to teams before PI planning. Another respondent viewed this development as some- 
thing natural since, in his ART at Auto, they were now better at assigning larger 
features for each team, which resulted in better knowledge within a specific area. 
Hence, further development of features within this area was naturally assigned to this 
team. The respondent claimed that this probably was different in different teams since 
some had not as dedicated areas as his team had. 

A related area, also expressed by several respondents was that requirements now, 
since the implementation of SAFe, were much more detailed in advance before the 
teams could see them. 


“It is hard to really feel something for the features when they are already very well detailed 
when we receive them.” - Team member at Auto. 


Two of the respondents saw this mainly as something negative, that the teams were 
not part of the detailing process. One respondent expressed a sense of “suffocation” 
because of less mandate in choosing what to work with. The third respondent was 
positive and meant that it helped the teams in understanding the requirements better. 

Four answers from the open-ended questions also display increased managerial 
control and loss of mandate for decision making for the team: “we still don’t get to 
select features to develop”, “too many managers/eaders compared to developers”, 
“the teams are too much top-managed. They are better at sorting out problems on their 
own”, and finally “it makes us work more like machines and less as humans”. 


4.4 Speak up 


One respondent expressed that there could be a downside to all joint activities 
implemented in SAFe with many people attending. 


> 


“If you are shy, SAFe is not any fun for you.” - Team member at Gov. 


She mentioned the system demo, where she claimed to know people that didn’t 
show all the details of a sprint result in fear of getting bad critique and be humiliated. 
She expressed this one step further by claiming that shy people will not like this way of 
working and that some colleagues once refused to present the teams PI plan in front of 
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other teams. Instead, they sent presentation slides in advance but did not show up and 
later claimed they had missed the meeting since they did not know at what time 
presentations should start at. 

Three answers from the open-ended questions expressed a loss of clarity due to 
problems with team members and stakeholders not speaking up: “harder to get clear 


responsibilities, things end up between chairs”, “unclear about who is in charge of 
problems that arise”, and “lost sense of personal responsibility and urgency”. 


5 Discussion 


When self-organizing teams need to work together, they must sacrifice some level of 
autonomy. As exemplified by Bass and Haxby, this will have impacts on creativity and 
autonomy to reach consensus on common standards [2], but few details on changes to 
autonomy have been put forth in research on large-scale agile ways of working. Even 
less have been studied when scale-up is performed by implementing a framework, such 
as the increasingly popular SAFe [1]. 

Therefore, the following research question was formulated: “How is team auton- 
omy affected by implementing the SAFe framework when agile software development is 
scaled up in the organization?”. The multiple-case study conducted at the three case 
organizations Auto, Gov, and Bank, shows how the joint activities with several teams 
form important arenas that affect autonomy in the single team. The PI planning event, 
for example, creates a better overview which seems to allow better possibilities to help, 
and receive help, from other teams. According to the respondents, this also appears to 
broaden competencies in the team, allowing even more cross-functionality to the team. 
The increased planning transparency seems to empower teams, even giving them more 
veto power to stop poor resource planning with overloaded teams. 

These arenas, however, do not seem to empower teams on their own. According to 
the interview respondents, they require people who dare to speak up, that are not shy or 
afraid to demonstrate plans proposed by the team in public. Respondents also reported 
a lost sense of personal responsibility and clarity regarding responsibility for solving 
emerging dependency issues. This further pinpoint the need for speaking up, to raise 
concerns, and clarify responsibilities. 

Several agile practitioners, Schwaber [8] for example, have criticized SAFe for 
being too strict and formal, thereby risking to suffocate teams under detailed routines 
and practices. Conboy and Carroll [9] confirm the risk of imposing too many restric- 
tions and rigidity when implementing large-scale frameworks from a study of thirteen 
agile transformations. This problem is somewhat supported in this study, especially 
regarding long-term planning routines. The “suffocation” expressed from team mem- 
bers relate to less mandate in choosing what to work with. Because of the added 
planning, pre-planning and refining routines, it seems as teams have lost much of their 
possibility to choose what to work with and to “feel” for the upcoming work, since 
much detailing has been conducted outside the team. 

A conclusion from the large-scale agile transformation at Ericsson [6], who 
invented and tailored their own practices, was that they probably would have benefitted 
from implementing a common framework instead. They thought such a framework 
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would have provided a common ground for team practices which could instead have 
been tailored later on [6]. Findings from this study, however, suggest that it is not that 
simple as having a shared framework. Implementing a framework such as SAFe could 
lead to other problems such as a “sense of suffocation” and less ability to choose 
between different features for the teams. 
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Abstract. The notion of autonomous teams is core to agile software develop- 
ment. However, autonomy in agile teams is challenged by increasingly complex 
software projects, large-scale agile and perhaps increasingly multidisciplinary 
teams. At the same time, data science roles are making their way into agile 
teams as companies seek to reap the potential advantages of using data to 
develop better and more competitive services and products. The consequences 
of implementing such roles in traditional agile teams are largely unknown. In 
this paper, we take an exploratory approach to the topic of data science roles in 
agile teams by a set of interviews with five data scientists as well as three 
members of an agile software development team. Based on the interviews we 
identify a set of challenges associated with incorporating the role in agile 
autonomous teams. Based on these challenges we discuss preliminary recom- 
mendations for companies seeking to integrate data science roles in agile teams. 


Keywords: Data science - Agile - Software development - Teams - Autonomy 


1 Introduction and Background 


During the past decades, agile practices have spread beyond the traditional software 
development team to include other roles, parts of the organization, and even the 
organization as a whole [1]. This introduces challenges such as adapting agile methods 
while keeping with the central aspects of team autonomy and balancing cross- 
functional teams with an efficient team size [2]. At the same time, the usage of data 
science in software development has expanded rapidly [1, 3], possibly introducing new 
challenges to agile team autonomy. 

The notion of team autonomy is not new. In most agile methods the notion of 
enabling teams to make decisions of their own is central [4]. Such teams are often 
labelled as self-managing, self-organizing or autonomous. These teams should be 
cross-functional, consisting of the roles needed for the team to utilize their competence 
to deliver across roles and organizational functions [5, 6]. The assumption is that cross- 
functionality contribute to more empowerment and participation within the team [5, 7]. 

Regardless of the label, merely assembling a group of people and naming them 
autonomous is not enough to ensure that the group acts as a self-organizing or 
autonomous team [7]. Some of the identified criteria important for team autonomy 
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include having a common goal and direction, a trusting team climate, organizational 
support and efficient skill utilization [4, 8]. 

The increasing scale and complexity of modern software development has led to 
new team constellations such as DevOps and BizDev teams [4], or more recently 
combining and adapting agile development practices to data science and machine 
learning [1]. Adding increasingly more roles to the agile, cross-functional team, may 
come with the side effect that autonomy and self-management is difficult to maintain [2, 
4]. In particular, introducing new roles such as data scientists into the cross-functional 
team may pose a challenge with conflicting interest and needs across team members 
with different backgrounds, terminologies and approaches to work. Indeed, balancing 
individual and team autonomy are among the key barriers to self-management [7]. We 
speculate that including data science roles into agile cross-functional teams will further 
complicate the landscape. 


1.1 Machine Learning in Organizations and the Need for Data Scientists 


Today, extreme amount of data is generated and stored every day. Organizations are 
trying to use this data to create new experience and products that are personalized for 
its users and to stay ahead of competitors. Leading stars in this area like Google, 
Facebook and Amazon, have succeeded in creating value from the data they store. The 
key elements of their success lie in a strong digital platform where all data generated 
can be easily accessed. Machine learning, a subfield of artificial intelligence, is cur- 
rently the preferred method to use in order to handle the extreme amount of data. 
Algorithms and statistical models search for patterns, make data-driven decisions and 
continuously improve themselves without human interference [9]. The people pos- 
sessing the skill set to work with this combination of computer science and statistics are 
often referred to as data scientists. This role is not to be mixed with other similar roles, 
such as data engineer and data analyst. Data engineers are more concerned with 
maintaining and building infrastructure so that the data becomes accessible [10]. Data 
analyst build reports and visualizations to explain what insight the data is hiding using 
statistical methods, but do not spend time programming advanced algorithms that the 
data scientist role does [11]. Often, the data scientist role in an organization can be 
described as a researcher trying to find meaning in the data and creating self-improving 
algorithms [1, 12]. The solutions they build can lead to tasks automation, personalized 
user content, and much more. 

Recently, more traditional organizations have begun to explore how to create value 
from data. Fleming et al. [13] point at different factors needed to build a data-driven 
organization. Among these, a key point is having the right competence, such as data 
scientists. However, merely hiring a data scientist and expect results is likely to be 
wishful thinking. According to Davenport [14], a good data-driven environment where 
data scientist can thrive should include a focus on (1) company culture, (2) analytics 
capabilities, (3) data and technology capabilities and (4) individual capabilities. Here we 
see that there are many factors involved in order to build a data-driven organization and 
incorporate the data scientist role. Patil [15] also points to the importance of close 
collaboration between data scientist and the rest of the organization, and that to create 
great data products you have to build cross-disciplinary groups. One can see this as an 
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argument to incorporate the data scientist role into cross-functional teams. A data sci- 
entist also needs a work environment where he/she can experiment and let the creativity 
blossom [15]. This may indicate that they need a high degree of individual autonomy. 


1.2 Research Question 


While organizations are increasingly making use of both data science on the one hand, 
and agile methods on the other, little research has examined the interplay between the 
two, in particular from an agile team perspective. For instance, Larson and Chang [1] 
examine how agile principles can be adapted and adjusted to data science, but do not 
discuss how the introduction of data science roles affects autonomy in the agile team. 
Kim, Zimmermann, DeLine, and Begel [3] discuss the role of data scientists in software 
development teams, but not agile or team autonomy. As such, our knowledge about 
including data science roles in agile autonomous teams remains limited. In this study, 
we explore the following research question: What challenges do agile autonomous 
teams face when introducing data scientist roles into the team? 

In this short paper, we take an exploratory approach to our research question. This 
first section has introduced the topics. Next, we describe our method and data col- 
lection procedures and present results from six interviews. Finally, we discuss the 
challenges identified from the results and suggest initial recommendations for practice. 


2 Method 


To explore our research question, we conducted six semi-structured interviews with an 
average length of 40 min. Five separate individual interviews with participants from 
three different organizations were conducted by the first author. The second author held 
a group interview with three participants from a fourth organization. Information about 
the respondents and their organizations are provided in Table 1. To avoid too much 
bias in our data by only interviewing people directly linked to the data science field, the 
group interview conducted by the second author was with people from an agile 
development team without data science experience. This gave us a more nuanced view 
of the data scientist role. Due to confidentiality agreements, further details about the 
organizations and their specific cases remain anonymous. 

During the interviews, we presented our participants with our research topic and 
asked them to describe their experiences with data science, agile methods, team 
autonomy and experiences with implementing data scientist roles into agile teams. We 
followed the semi-structured approach, asking prepared questions but also allowing the 
conversations to naturally develop. During the former five interviews, detailed notes 
were taken, while the group interview was tape recorded based on consent and tran- 
scribed by the second author. After the interviews, the authors read through each 
other’s notes and transcriptions, before discussing common topics that had emerged. 
Next, we separately coded the data. Due to the exploratory approach, the relatively 
short interview records, and low number of interviews we chose a holistic coding 
approach [16, 17]. As themes started to emerge, we discussed and resolved any dis- 
agreements in coding and interpretation. 
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Table 1. Data sources 


Participants Organization and team description 
Pl Large private consultancy organization. Data scientist team lead, leading a 
team of two data scientists, 3-4 data engineers, one architect, one security 
architect 
P2 and P3 Large public sector organization. P2 Lead for data scientist department. P3 
data scientist 
P4 and P5 Small start-up specialized in data scientist tasks. P4 CEO and data scientist 
team lead. P5 data scientist 
Group Three participants from a large public sector organization; one team leader, 
interview one tech lead and one interaction designer 
3 Results 


In this section, we present the results from the interviews, focusing on the main 
challenges with establishing the data scientist role in autonomous teams. Based on what 
our respondents told us, and discussion and analysis of the data between the two 
authors, six challenges and possible recommendations are summarized in Table 2. 


Table 2. Main challenges identified during interviews 


Challenges Recommendation 

1. Agile methods Arrange team kick-off, allow time for the team to settle in and 
mature 

2. The data scientist role Provide training; Make a dictionary for key terms and 
expressions 

3. Additional data roles Adjust agile practices; What can be adapted to meet the needs 


of the DS? Adjust agile practices; What can be adapted to meet 
the needs of DS? 


4. Creativity and freedom Facilitate for Community of Practice (CoP) 


5. Collaboration and Consider if additional “data roles” are needed 
knowledge sharing 


6. Data platforms and Build a data platform to gather data in one place 
infrastructures 


3.1 Agile Methods 


Agile methods were employed to various degrees in all the respondents’ teams. 
Although their perceptions varied, all of them also had some understanding of what it 
meant to be autonomous. Many used Scrum practices such as stand-up meetings, 
sprints and retrospectives. According to the data scientists in our sample, the usage of 
sprints could be challenging. P4 explained that it can be hard to work according to a 
sprint schedule, since a data scientist work out from hypotheses, which not always give 


Exploring the Challenges of Integrating Data Science Roles 41 


something of value from a management and team lead point of view. However, as P4 
stated, for a data scientist this provides insight about what is not working, and then can 
test other methods in the next sprint. 


3.2 The Data Scientist Role 


From the interviews it became quite clear that “The definition of a data scientist has 
become more blurred” (P1), and that this misconception lead to wrong expectations 
about what a team want the data scientist to solve, preventing the realization of the full 
value of having this role on the team. P3, also a data scientist, used her first months in 
the company working partially for different teams explaining what a data scientist is 
and what use-cases are suited for them to solve. In the group interview they claimed to 
have a data scientist on the team, but after we analyzed the interview it became clear 
that this role was actually a data analyst. They also explained that it could be hard to 
understand the terminology of the data scientist. 


3.3 Additional Data Roles? 


All respondents who held data scientist roles expressed that a data scientist in team 
should ideally be supported by a data engineer. P1, P4 and P5 explained that a data 
engineer’s job is to create the infrastructure, so the data becomes easily available for the 
data scientist. Without data, it is hard for the data scientist to do their job. They further 
explained that teams lacking both roles might need to increase their total numbers of 
members with two or more. P3 said that one additional resource to the team might not 
be a big deal, but when first including one more resource, it is easy to add a couple 
more. However, according to P3, if there are too many resources on a team it can lose 
its autonomy. 


3.4 Creativity and Freedom 


To experiment and explore the data was highlighted as important for data scientists to 
thrive. For example, P3 explained that an important part of her job is to test and explore 
different hypotheses, and if the environment she works in is too rigid, it becomes 
difficult for her to do her job. This is also backed up by P1, P4 and P5. Although 
creativity and freedom are important, they also stated that management must point out 
the bigger problem they are going to solve. P4 explains that data scientists need a high 
degree of autonomy: “A project manager should never tell a data scientist how to do 
things. Just tell them what are the overlaying problem that needs to be solved and when 
deadline is”. 


3.5 Collaboration and Knowledge Sharing 


Collaboration and knowledge sharing among data scientist were also highlighted as 
important. P2, who leads a data scientist lab, stated that a data scientist should not 
allocate all its time to a team project, but also use time working together with other data 
scientists. This is important she said, because it is one of the best ways a data scientist 
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can grow and learn. P3 explained that the time spent with other data scientist is 
valuable and is used to create and test different types of algorithms and make data 
science tools that can be reused across multiple projects. Along similar lines, the 
participants in the group interview expressed concern that their data analyst did not 
have sufficient opportunities for knowledge sharing with peers. 


3.6 Data Platforms and Infrastructure 


Data platforms and infrastructure was a final theme emerging from the interviews. All 
the data scientists expressed the need for easy access to data. Both P4 and P5 explained 
that a good infrastructure should be in place and that a data platform is necessary. 
Without it, it will be hard for the data scientist to do productive work and would use 
most of the time chasing data. This, they said, would not benefit neither the data 
scientist nor the team. 


4 Discussion and Concluding Remarks 


We now turn to discuss our research question “What challenges do agile autonomous 
teams face in introducing data scientist roles into the team?” 

We believe that understanding what a data scientist is and can do is key for a team to 
successfully incorporate the role. The confusion about the role, as seen from the group 
interview, can lead to sub-optimal use of the data scientist. This again can have negative 
effect both for the team and the data scientist. Therefore, it is important to train the team 
about what the data scientist can and should contribute with. It could be important that the 
team set a side time to manage expectations, both within the team and outwards to the rest 
of the organization. One way to manage expectations is to understand there may be 
different views of what value is. Often a team lead or manager have a different under- 
standing of value than a data scientist. A machine learning implementation that after two 
weeks of work did not function as expected, would still in the data scientist eyes provide 
value in form of knowing what algorithms did not work so well and learn from the 
experience. However, a manager could see it as a failure and would struggle to find 
something of value. Therefore, when integrating new roles into the team, it might help the 
team to reflect upon the different aspects and views of value. 

Also, an idea when building a data scientist environment might be to have data 
scientist partially in teams, and then train the teams in what use-cases is appropriate for a 
data scientist and help them understand the fields’ terminology. Another suggestion is to 
arrange team kick-offs to work with specific data scientist use-cases, so the other team 
members becomes familiar with the topic. In a team kick-off one should also reflect on 
agile practices and if they need to be adapted to the inclusion of a data scientist. 

One should also be mindful about other potential expansions of a team when 
including the data scientist role. A variety of roles could be needed, in addition to the 
data scientist, for a team to become data-driven [13]. An increased team size can lead to 
loss of team autonomy and agility [2]. Therefore, one should think carefully about if 
other roles must be added to support the new data scientist role. An alternative solution 
could be to see if current team members can be trained to take on additional roles. 
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Training current team members to become data scientist might not be feasible, as the 
role require high expertise of both statistics and programming skills. It would likely 
take a lot of time and investment to retrain a person for that role. For example, a data 
analyst might have the necessary statistical background but lack the programming 
experience, while a software developer lacks the mathematical background. 

Alternatively, instead of focusing on training team members to become data sci- 
entists, it might be a better solution for the organization to train its members in skills 
which could help support the data scientist in its work. That way a team might avoid 
the increase in roles when adding a data scientist to the team. Instead of adding a couple 
of data engineers join the team, their tasks can be done by current team members, for 
example building a better infrastructure and provide the data scientist with an archi- 
tectural overview. 

Throughout the interviews, the importance of collaboration with other data scien- 
tists were highlighted. As pointed out by Davenport and Patil [12] there is a trade-off 
between working in cross-functional groups versus interaction with other specialists 
within their own field. Towards this end, organizations can establish Communities of 
Practice (CoP) where data scientists can exchange and discuss ideas, develop profes- 
sional skills and new ways of working. CoP’s are important for knowledge sharing, 
coordination and decision-making in large-scale agile development projects [18, 19]. 
An open data science CoP could contribute both to the data scientists’ skill develop- 
ment, but also raising the understanding of other organizational members. 

The creativity and freedom a data scientist require can be seen as the need for a 
high degree of individual autonomy. This notion is supported by Patil [15], but he does 
not say anything about how it might affect self-managing teams. In Moe et al. [7] the 
difficulty of balancing individual autonomy and team autonomy is discussed. They 
explain having greater redundancy in the team can reduce this problem. This redun- 
dancy the data scientist can use to engage in CoP’s. Of course, one can also debate if 
the creativity and freedom the data scientists talk about in the interviews is the exact 
same kind of freedom and creativity any role in an autonomous team need. However, 
given the current popularity the data scientist role has in the industry it might be that it 
feels more natural for the data scientists to talk about it. 

Although soft skills are necessary to succeed with implementing the data scientist 
role into the team, we cannot get by the fact that certain technical conditions must be 
fulfilled as well. A data-driven platform is a critical component in order to build an 
organization that aim to make data-driven decisions and utilize the competence of data 
scientists [20]. A platform is also seen as an important prerequisite for team autonomy 
[21]. Therefore, if traditional industries are going to succeed with integrating data 
scientist and let them work autonomous, it is important that they have access to all the 
data through a digital platform. 

As a concluding remark, this is an ongoing study and the findings are preliminary. 
We recognize the important limitations, such as the use of a convenience sample and 
single-source design [17]. The fact that several of our respondents were data scientists 
themselves may represent a bias in the data gathered from the interviews. As mentioned 
in the method section, to nuance the sample we included the group interview with agile 
team members working with a data scientist. Further, the recommendations in Table 2 
have not been validated and are only suggestions made by the authors. Future studies 
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with more rigorous design and methods are needed in order to establish confidence in 
our findings. Future research could also include inter- and intra-team coordination, as 
team constellations including data scientist roles should be likely to be large-scale 
projects. Notwithstanding the limitations of this exploratory study, we believe more 
research-based knowledge on implementing data science roles in agile teams is 
important as organizations continue to make use of and combine data science and agile 
methods. 
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Abstract. Motivation: Many companies aim to provide more auton- 
omy to their development teams. While some teams report on successes, 
others still struggle with the agile adaption, e.g. due to the organisa- 
tional environment. Objective: Our objective was to explore how organi- 
sational culture and structure influence team autonomy in bureaucratic 
companies. Method and Results: 30 qualitative interviews from different 
business divisions at a conglomerate revealed that organisational factors 
related to hierarchy, specialist culture and functionally departmentalised 
structure decreased agile team features and consequently resulted in a 
reduced speed of decision-making. We suggest the Agile Matching The- 
ory which implies that prevalent organisational factors and desired agile 
team features need to match to allow team autonomy to occur. Conclu- 
sion: We therefore encourage managers to further work on a learning 
organisation and a supportive structure within which autonomous teams 
can grow. 


Keywords: Autonomous teams - Challenges - Bureaucracy 


1 Introduction 


Many companies started the agile transformation by implementing autonomous 
teams. Team autonomy implies to make team decisions regarding task allocation 
and execution as well as solve problems independently [12]. While narratives 
postulate great success stories on agile teams, empirical evidence often reveals 
how difficult it is for teams to work in an agile way [8,9, 14]. 

Specifically teams in bureaucratic companies appear to face obstacles in 
working autonomously [1,17]. A mismatch between prevalent organisational fac- 
tors and agile team behaviour was identified to serve as a major challenge for 
autonomous teams [9,15,21]. This paper specifically focuses on implementing 
autonomous teams in bureaucratic organisations. This type of organisation con- 
tradicts the agile way of working [17]. It is used to rely on a hierarchical culture 
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as opposed to autonomous teams |14], on rigid planning as opposed to iterative 
team learning [1] and on operating in a functional departmentalised structure 
as opposed to cross-functional teams [17]. Thus, we can assume that teams that 
aim at effectiveness struggle with working in an agile way if the necessary pre- 
conditions on the organisational level aim at supporting efficiency. Yet, scarce 
research examines the link between the organisational context and agile team 
behaviour [2,9,21]. Teams that are implemented in rather bureaucratic environ- 
ments tend to struggle with working in an agile manner due to hindrances on the 
organisational level without the legitimate power to change their environment. 
To be able to support agile teams properly, management needs to know how 
organisational factors influence team behaviour. This study focuses on the influ- 
ence of a bureaucratic environment on team autonomy. Our research question 
is therefore: How do organisational culture and structure influence autonomy of 
teams? 

We have conducted semi-structured interviews with 30 individuals from 11 
different Scrum teams at the Robert Bosch GmbH. Interviewees elaborated on 
successes but also on challenges. This study reports on the challenges with a spe- 
cific focus on how the predominantly bureaucratic environment on the organisa- 
tional level influences the agile way of working on the team level. Data revealed 
that a strong hierarchy, a specialist culture and functional departmentalised 
structures decreased agile team features such as psychological safety or team 
learning and consequently team autonomy. We suggest the Agile Matching The- 
ory which implies a mandatory fit between prevalent organisational context and 
desired agile team features to enable teams to act autonomously. 


2 Background 


Agile teams are described to work cross-functionally within and across bound- 
aries [3] with a high level of autonomy based on a common goal [2,22]. This paper 
considers the agile team features monitoring [16], psychological safety [5], team 
potency [18], shared mental models [13], team learning [5] and team orientation 
[16] to be predecessors of team autonomy. 

Autonomy can be clustered into individual autonomy which provides a team 
member a high level of freedom regarding fulfilling a task [11], team autonomy 
which refers to shared decision making within teams and external autonomy 
related to interference by management [10]. External autonomy may not only 
refer to hierarchical culture [8,14,17], but also to a specialist culture [8,15] or 
to a functionally departmentalised structure including rigid processes [1, 4,17] or 
geographical distribution [22]. 

Hoda and Noble [9] explain agile adaption by a link between organisational 
context and agile teams and call for further research on the dependency among 
the two levels of analysis. Yet, most research does not focus on exploring the 
relationship between organisational factors and its influence on team autonomy 
specifically. Furthermore, researchers tend to examine agile team challenges by 
mainly interviewing managerial positions [4,9]. 
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We examined the influence of external autonomy on team autonomy by pre- 
dominantly interviewing team members. Our results suggest the Agile Matching 
Theory which implies that team autonomy depends on the match between the 
prevalent external autonomy on the organisational level and desired agile team 
features. If the organisational context does not match with the required agile 
features on the team level, most likely team autonomy will be low (Table 1). 


Table 1. Organisational factors and agile team factors 


Bureaucratic organisation Agile team factors 

(1) Hierarchical culture [8, 14,17] Monitoring themselves [16] 
Psychological safety [5] 
Team potency [18 
(2) Specialist culture [8,15] Shared mental models [13] 


Team learning [5] 


Team orientation [16] 
(3) Functionally departmentalised [23] Shared mental models [13] 


Team learning [5] 


Team orientation [16] 


Reality: limited external autonomy Desire: high team autonomy 


Since contextual factors are mostly set by management [9,15] our results help 
managers to be aware of the boundary conditions teams should receive to be able 
to act autonomously. 


3 Study Design 


3.1 Research Context 


We draw our sample from 5 different business divisions at the Robert Bosch 
GmbH. Founded in 1886 it became excellent in the bureaucratic way of working. 
Starting its agile journey in 2012 it is now in the middle of its transformation 
efforts. At present, some 410,000 employees are active in four different busi- 
ness areas each embracing multiple divisions with slightly different sub-cultures. 
While several divisions are already in the forefront of its agile transformation, 
others have started its journey just recently. 

The sample contains 30 individuals from 11 different Scrum teams operating 
at 5 different business divisions, mainly active in the automotive industry. The 
sample contained 5 software and 6 non-software development project teams. 
We interviewed 6 Scrum Masters (SM), 4 Product Owners (PO) and 20 team 
members (TM). The age of projects ranged from 2 months up to 3 years. Team 
size ranged from 5 up to 12 members, often including individuals from different 
nationalities. 
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3.2 Data Collection and Analysis Procedure 


We chose Grounded Theory because it allows for an exploratory approach in 
rather new scientific fields [7]. Additionally, we observed teams in their daily 
activities to understand the context of interviewees better. To answer the 
research question, we conducted qualitative semi-structured interviews of 45 min 
on average. We asked participants to elaborate on challenges concerning their 
current Scrum project. The questionnaire can be found online [19].' We audio- 
taped and transcribed each interview. We openly coded transcripts sentence- 
by-sentence and aligned codes that appeared to be alike to one concept and 
constantly reflected those concepts critically [7]. 

The organisational level contained the three categories high power distance, 
expert culture and functionally departmentalised structure which each consisted 
of a bundle of concepts. For example, the category high power distance involved 
the concepts several hierarchical layers included in decision making, positional 
legitimacy and management overrules. Those categories influenced six agile fea- 
tures on team level and decreased team autonomy. 

Through constant comparison of various interviews we identified a mismatch 
between organisational factors and the core features of agile teams as major 
challenge in our research context. Based on three propositions we suggest The 
Agile Matching Theory which implies that a low team autonomy results from a 
misfit between prevalent organisational factors and desired agile team features. 

Limitations: Since we only draw data from one company our results are lim- 
ited to our research context and cannot be generalised. Thus, future testing of 
the propositions should draw data from different conglomerates. Furthermore, 
our findings are based on qualitative interviews and therefore, need to be con- 
firmed by quantitative testing. More details on the recruitment of participants, 
the organisational context, validity procedure and limitations of the research are 
available elsewhere [20]. 


4 Findings 


The findings describe challenges regarding organisational culture and structure 
and how each factor influenced autonomous teams. 

Interviewees often mentioned that organisational culture linked to high 
power distance and specialised knowledge workers reduced external autonomy. 
High power distance was exemplified by several hierarchical layers which all 
needed to be included in decision-making processes even though some were said 
to not even add value, by management or Product Owner that felt to have the 
right to overrule team decisions or told the team what they had to do and by sta- 
tus legitimacy. As a result, sometimes team members reported to be frustrated, 
demotivated or to fear that management or Product Owner would overrule their 


1 The collected data are drawn from a broader research project on the Scrum Master 
role [20]. 
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decisions anyways. Thus, low external autonomy resulted in a low level of self- 
monitoring, of psychological safety and of team potency. Which led to a lack of 
willingness and capability to make team decisions. 


If think, maybe if the Product Owner would not tell me everyday what I 
have to do, maybe I would be more intrinsically motivated to do my tasks, 
maybe I would chose my tasks voluntarily. But like this. . . I just deliver 
a status report to my Product Owner every day! (TM) 


But you don’t necessarily receive decisions, you don’t get information if 
you go there and say: hey, I am a team member of the agile team. If you 
go there as a common team member, you only get the information if you 
are in the proper hierarchical layer, only if you talk to a person at the same 
hierarchical level. That are the power plays. (TM) 


We therefore suggest the following proposition: 


(P1) High power distance leads to a low level of team autonomy (1a). This 
relationship is moderated by monitoring (1b), psychological safety (1c) and 
team potency (1d). 


A specialist culture was described by territories and by a lack in readiness 
to experiment. Some managers were said to prefer teams to follow a strict plan 
that was thoroughly thought through in advance and were reluctant to apply an 
inspect and adapt approach. 

Territory refers to an expert who enjoys a sovereign right to keep specific 
knowledge and even the respective task all to him- or herself without sharing 
it. Therefore, other team members did not feel responsible or allowed to learn 
the specific knowledge. Interviewees also referred to a lack of willingness to learn 
things unrelated to the personal field of expertise or to a lack of discipline to not 
dig too deep into an expert topic. 


Well, there are clearly defined areas in this team. Territories which are 
well hidden. You need some time to recognize them. [...] certain people are 
in certain territories which is simply inflexible. You realize this when there 
is one topic dropped, it is not considered. And than there are the people 
waiting and have nothing to do, even though there actually needs quite a 
lot to be done. Because there are the territories that you are not allowed 
to enter and than one does not work together. (SM) 


While some team members appeared to own high individual autonomy 
regarding tasks, they had a low team autonomy. Thus, a specialist culture 
resulted in weak team learning, shared mental models and team orientation and 
consequently lead to low team autonomy. We therefore suggest the following 
proposition: 
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(P2) A specialist culture leads to a low level of team autonomy (2a). This 
relationship is moderated by shared mental models (2b), team learning (2c) 
and team orientation (2d). 


Some interviewees described the organisational structure as functionally 
departmentalised. It involved the categories departmental silos, department- 
oriented goals, geographical distribution and rigid processes. 

Teams reported that they had to rely on external know-how due to processes 
which slowed them down. Some teams that depended on external support had 
difficulties in receiving a timely response or even at all. 


If a team is not both at the same time - a self-organized team and the 
company itself - you always need interfaces, stuff from other people. And 
especially big companies are often divided into silos, which makes it very 
very difficult. You always need to wait for stuff. You ask for something 
and then you don’t get it. And you do something, you show it to someone 
and then they don’t respond. [...] or because they simply don’t have time to 
respond. (PO) 


Sometimes, different sprint goals or contrasting departmental goals resulted 
in slow decision-making. For example, purchasing would try to reduce costs while 
developers searched for the technically best solution which would be more expen- 
sive. Some agile teams reported to clash with traditional teams that followed a 
classic project plan in contrast to iterative learning. Those neighbouring project 
teams were considered to be slow and inflexible in relation to agile teams, which 
made it difficult to synchronise project goals and milestones. Interviewees also 
said that it was a challenge to include external experts for the up-coming sprint 
in advance. Furthermore, geographical distribution limited knowledge exchange, 
synchronisation of progress, visualisation, discussions about critical topics and 
decision making. 

Therefore, a functionally departmentalised structure resulted in weak shared 
understanding, team learning and team orientation. This leads to slow team 
decision-making. We suggest the following proposition: 


(P3) A functional departmentalised structure leads to a low level of team 
autonomy (3a). This relationship is moderated by shared mental models 
(3b), team learning (3c) and team orientation (3d). 


5 Implication for Research and Practice 


We found that high power distance, specialist culture and a functional depart- 
mentalised structure decreased team autonomy. Since people behave accord- 
ing to the context within which they operate [2] we suggest that teams can 
only act autonomously if they face the necessary preconditions on the organi- 
sational level. For example, management can destroy the self-organising nature 
easily (e.g. [8,9,14]) by making decisions on behalf of the team. Therefore, even 


52 S. V. Spiegler et al. 


though companies aim at implementing agile teams, team autonomy will remain 
low when a company does not simultaneously provide a high level of external 
autonomy by changing the organisational culture and structure. 

The agile way of working is based on shared values, believes and a common 
goal, anormative approach while bureaucratic organisations are based on written 
rules, standards, processes. Therefore, established companies that have already 
started its agile transformation by implementing agile teams have to increase its 
efforts even further to empower real autonomous teams by putting even more 
effort into changing the organisational structure and culture. 

We have observed several promising initiatives in established companies to 
start an agile transformation by setting up autonomous teams in protected yet 
even isolated clusters. Providing a guarded environment to let teams, manage- 
ment and the surrounding structures try, experiment, learn and accept new ways 
of collaboration for too long brings the risk that those “islands” will only exist as 
such. Established companies that have made first experience with working in an 
agile way and that have created valuable insights must take the next challenging 
step to introduce their individual learning episodes to a broader organisational 
level and to expand their activities to those structures that seemed not ready 
yet, by providing similar values, believes as well as goal setting and to nourish 
from the success of their protected test teams. 

Companies should foster a learning organisation [6] that encourages employ- 
ees to continuously share knowledge openly and to learn from each other unre- 
lated to their position or functional structure. This requires tools and commu- 
nities to allow for transparency, e.g. social business platforms that are easily 
accessible. The opportunity to contribute and to be acknowledged for knowledge 
sharing among team members and communities intrinsically motivates individ- 
uals and fosters team learning and creativity [22]. Therefore, management needs 
to foster knowledge management tools and experiments to incentive those that 
actively share or promote knowledge and to provide more work time for com- 
munities of practice and open space meetings. 

The Scrum method suggests dedicated full-time team members that own all 
competences needed to fulfil a given task. Yet, since this is often not possible: In 
reality teams have to call in experts according to their sprint goals. This requires 
an open organisation with easy access to different competences and skills. 

We contribute to existing research by providing more insights on how organi- 
sational factors can challenge team autonomy. While many companies report on 
success stories on autonomous teams this research provides a brief insight on the 
challenges. This study is one further step to help management understand how 
culture and structure limit autonomy of agile teams. More research is needed to 
understand supporting and hindering factors and to how they apply in reality. 


Autonomous Teams in Established Companies 53 


References 


13. 


14. 


15. 


16. 


17. 


18. 


19. 


20. 


Boehm, B., Turner, R.: Management challenges to implementing agile processes in 
traditional development organizations. IEEE Softw. 22(5), 30-39 (2005) 
Cockburn, A., Highsmith, J.: Agile software development, the people factor. Com- 
puter 34(11), 131-133 (2001) 

Conboy, K.: Agility from first principles: reconstructing the concept of agility in 
information systems development. Inf. Syst. Res. 20(3), 329-354 (2009) 

Conboy, K., Coyle, S., Wang, X., Pikkarainen, M.: People over process: key people 
challenges in agile development. IEEE Softw. 28(4), 47-57 (2011) 

Edmondson, A.: Psychological safety and learning behavior in work teams. Adm. 
Sci. Q. 44(2), 350-383 (1999) 

Garvin, D.A., Edmondson, A.C., Gino, F.: Is yours a learning organization? Har- 
vard Bus. Rev. 86(3), 109 (2008) 

Glaser, B.G., Strauss, A.L.: Discovery of Grounded Theory: Strategies for Quali- 
tative Research. Routledge, Abingdon (2017) 

Hoda, R., Murugesan, L.K.: Multi-level agile project management challenges: a 
self-organizing team perspective. J. Syst. Softw. 117, 245-257 (2016) 

Hoda, R., Noble, J.: Becoming agile: a grounded theory of agile transitions in prac- 
tice. In: Proceedings of the 39th International Conference on Software Engineering, 
ICSE 2017, Piscataway, NJ, USA, pp. 141-151. IEEE Press (2017). https://doi. 
org/10.1109/ICSE.2017.21 


. Hoegl, M., Parboteeah, P.: Autonomy and teamwork in innovative projects. Hum. 


Resour. Manag. 45(1), 67-79 (2006) 


. Langfred, C.W.: The paradox of self-management: individual and group autonomy 


in work groups. J. Organ. Behav. 21(5), 563-585 (2000) 


. Leach, D.J., Wall, T.D., Rogelberg, S.G., Jackson, P.R.: Team autonomy, perfor- 


mance, and member job strain: uncovering the teamwork KSA link. Appl. Psychol. 
54(1), 1-24 (2005) 

Levesque, L.L., Wilson, J.M., Wholey, D.R.: Cognitive divergence and shared men- 
tal models in software development project teams. J. Organ. Behav. 22(2), 135-144 
2001) 

Moe, N.B., Aurum, A., Dyba, T.: Challenges of shared decision-making: a multiple 
case study of agile software development. Inf. Softw. Technol. 54(8), 853-865 (2012) 
Moe, N.B., Dingsgyr, T., Dyba, T.: Overcoming barriers to self-management in 
software teams. IEEE Softw. 26(6), 20-26 (2009) 

Moe, N.B., Dingsdyr, T., Dyba, T.: A teamwork model for understanding an agile 
team: a case study of a scrum project. Inf. Softw. Technol. 52(5), 480-491 (2010) 
Nerur, S., Mahapatra, R.K., Mangalaraj, G.: Challenges of migrating to agile 
methodologies. Commun. ACM 48(5), 72-78 (2005) 

Schmidt, C.: Agile Software Development Teams. Springer, Heidelberg (2016). 
https: //doi.org/10.1007/978-3-319-26057-0 

Spiegler, S.V., Heinecke, C., Wagner, S.: Interview Guidelines for “Leadership Gap 
in Agile Teams: How Teams and Scrum Masters Mature” (2018). https://doi.org/ 
10.5281 /zenodo.2243113 

Spiegler, S.V., Heinecke, C., Wagner, S.: Leadership gap in agile teams: how teams 
and scrum masters mature. In: Kruchten, P., Fraser, S., Coallier, F. (eds.) XP 2019. 
LNBIP, vol. 355, pp. 37-52. Springer, Cham (2019). https: //doi.org/10.1007/978- 
3-030-19034-7_3 


54 


21. 


22. 


23. 


S. V. Spiegler et al. 


Stray, V., Moe, N.B., Hoda, R.: Autonomous agile teams: challenges and future 
directions for research. In: Proceedings of the 19th International Conference on 
Agile Software Development: Companion, XP 2018, pp. 16:1-16:5. ACM, New 
York (2018). https://doi.org/10.1145/3234152.3234182 

Takeuchi, H., Nonaka, I.: The new new product development game. Harvard Bus. 
Rev. 64(1), 137-146 (1986) 

Weber, M.: The Theory of Social and Economic Organization. Simon and Schuster, 
New York (2009) 


Open Access This chapter is licensed under the terms of the Creative Commons 
Attribution 4.0 International License (http://creativecommons.org/licenses/by/4.0/), 
which permits use, sharing, adaptation, distribution and reproduction in any medium 
or format, as long as you give appropriate credit to the original author(s) and the 
source, provide a link to the Creative Commons license and indicate if changes were 
made. 


The images or other third party material in this chapter are included in the chapter’s 


Creative Commons license, unless indicated otherwise in a credit line to the material. If 
material is not included in the chapter’s Creative Commons license and your intended 
use is not permitted by statutory regulation or exceeds the permitted use, you will 
need to obtain permission directly from the copyright holder. 


t) 


Check for 
updates 


Agile Autonomous Teams in Complex 
Organizations 


Marius Mikalsen!” ) Magne Nesje’, Erik André Reime’, 
and Anniken Solem!” 


1 SINTEF Digital, Trondheim, Norway 
marius.mikalsen@sintef.no 
? Norwegian University of Science and Technology, Trondheim, Norway 


Abstract. In complex organizations, the effective functioning of autonomous 
teams is challenged by the need to coordinate and align work with multiple 
experts and other units in the organization. We report on the challenges expe- 
rienced in an agile program consisting of cross-functional teams set up with 
resources from both the IT and business development side of the organization, 
while team members simultaneously remain in their line organization. Through 
an empirical case study of the agile program, we find that the production 
structure (i.e. the distribution of operational tasks) and the control structure (i.e. 
managing activities related to the operational task) influence agile team auton- 
omy. We contribute by pushing past describing dependencies in terms of 
coordination challenges and mechanisms. To do this, we use modern 
sociotechnical theory to discuss how a production structure with many depen- 
dencies cause challenges and how a misaligned control structure is time- 
consuming and reduces team autonomy. 


Keywords: Agile - Autonomous teams - Complex organizations - Case study - 
Modern sociotechnical theory 


1 Introduction 


With increased digitalization, organizations face rapid changes in customer demands, 
changing markets, and continuous technological advancements. It forces established, 
traditional non-agile, complex organizations to make their software development more 
agile. By complex, we depict an organization with many units, with dependencies 
amongst them. The number of units and the strength of the dependencies determines 
the complexity. Traditionally, bureaucracy, plans, and hierarchies have addressed 
complexity. Agile ways of working are different, and extant research has not suffi- 
ciently addressed the issue of introducing agile autonomous teams within complex 
organizations [1, 2]. Introducing agile teams in a complex organization will cause 
challenging dependencies on condition that the surrounding organization remains plan 
based and hierarchical [3]. However, our knowledge of how such dependencies 
influence the autonomy of agile teams is limited, hence our RQ: How is complexity in 
organizations influencing the autonomy of agile teams? 
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We answer this question through an empirical case study of an agile program 
(henceforth referred to as AP) consisting of autonomous agile teams within a bank. The 
teams in AP are cross-functional, being staffed with personnel from both business and 
IT units. The number of dependencies between people, tasks, knowledge, technical 
assets, and other resources makes this a complex organization. 

To analyze our findings, we use modern sociotechnical theory (henceforth referred 
to as MST). MST is concerned with meeting dynamic business environments by 
designing flexible organizations. MST problematizes structural issues of production 
and control, and in this case, how these influence agile autonomous teams. 


2 Theoretical Background 


Agile and Autonomous Teams 

Team autonomy and diversity is reported to be key in achieving agility [4]. The process 
of forming and implementing teams with high autonomy, as well as the effective 
functioning of such teams, are not yet adequately addressed and understood in the 
context of complex organizations [5]. To understand autonomous teams in complex 
environments, it is crucial to understand the organizational context surrounding the 
team as it is an important determinant of effectiveness [6], effecting the potential for 
autonomy. Thus, there is a need for new knowledge on how to organize for and utilize 
autonomous teams, in order to attain better performance, productivity, innovation and 
value creation, hence increase competitiveness. 


Agile autonomous Teams in Complex Organizations 

While agile and autonomous teams have shown success in smaller projects, introducing 
such teams in complex organizations is known to be challenging [1]. Complex orga- 
nizations are more challenging because there are many dependencies, which tradi- 
tionally have been controlled through plans, hierarchies and standardization [2]. 
Dependencies exist between agile teams, and from agile teams to the rest of the 
organization [7]. As agile and autonomous teams are introduced within complex 
organizations, it may be problematic to scale agile coordination and communication 
practices from the team level, as such a change requires a change in organizational 
structure and processes [8]. 

When introducing agile teams in an organization that is otherwise traditionally 
organized, this can imply that the teams are being restricted by the rest of the orga- 
nization operating in plan and waterfall mode [8]. This has led some suggest that it is 
necessary that all departments “transform” if one is to gain full benefit from agile [3]. It 
seems that new insight on how to deal with complex interactions and dependencies is 
required [7, 9], as discussed next. 


Modern Sociotechnical Theory (MST) as a Lens on Dependencies 

The motivation behind modern sociotechnical theory (MST) is meeting dynamic 
business environments (e.g. rapidly changing user behaviors and technology) by 
designing flexible organizations. A flexible organization is achieved by creating 
complex jobs within simple organizations [10]. This approach is similar to the thinking 
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behind agile ways of working and autonomous teams. Bureaucratic organizations, due 
to their focus on maximum division of labor and central control over core work 
processes, do not fare well in dynamic environments [11]. 

Originating from a tradition focusing on how organizations are structured, MST puts 
emphasis on how structural complexity (e.g., the degree of team dependency towards 
other teams and functional units) in organizations influences team autonomy and 
production [12]. The theory describes how disturbances (i.e. unplanned events) orig- 
inate from dependencies that can be traced to the configuration of the organizational 
structure. 

MST divides the organizational structure into production and control structure [10]. 
The production structure describes the distribution of operational tasks across actors, 
and their relation (e.g. a business developer and a software developer cooperating to 
develop a new feature). The control structure describes the distribution of regulatory 
tasks, that is, managing activities related to the operational task (e.g. a PO managing the 
above-mentioned development). A job entails a set of operational and regulatory tasks. 

When the handling of disturbances to production involves actors outside the task 
(such as a manager), it is considered an external regulation. When the handling is 
within the task without interfering with the environment, it is considered an internal 
regulation. At the core of MST is a two-step structural redesign [11]. The first step is to 
create a production structure with few dependencies that minimize disturbances. Sec- 
ond, the goal of the control structure is to decentralize decision making-authority, 
creating an amplified regulatory potential (i.e. ability to perform regulatory tasks) that 
is aligned with operational tasks (e.g. enabling teams’ opportunity to handle remaining 
disturbances). MST has concepts for understanding organizational structures, depen- 
dencies, and disturbances. Thus, it can be used to deepen our understanding of agile 
autonomous teams established in complex organizations. 


3 Case and Method 


Case Background 

This study is a part of a longitudinal interpretative case study [13] of agile autonomous 
teams set in a Norwegian bank (dubbed NorBank for anonymity), with more than 2,000 
employees. NorBank initiated in 2017 an agile program (AP) consisting of five cross- 
functional autonomous teams organized in line with agile principles, with the goal of 
developing improved software for their business-to-business solutions in the insurance 
market. The teams consist of resources from both the IT and business development side 
of the organization. A product owner (PO), who is responsible for realizing the team’s 
delivery and goals, as well as managing the customer relationship, leads each team. 
Importantly, and which is often the case in complex organizations, members of the 
teams remained organized in a line organization (such as the IT and business side) and 
partake in several projects simultaneously. Therefore, the teams are staffed with part- 
time resources, particularly from the IT side. AP is managed by a group consisting of 
relevant IT and business managers from NorBank units which AP interfaces with. The 
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POs and a business architect also participate in this management group. NorBank has a 
set of legacy systems to which the solutions developed by the AP depends. 


Data Collection and Analysis 

The empirical data was collected in four rounds, using semi-structured interviews, 
observations of retrospectives carried out in AP and feedback sessions (Table 1). In 
order to qualitatively analyze our empirical findings, we used the stepwise deductive- 
inductive method (SDI) [14]. The inductive purpose of the SDI-method is to move 
from raw data, through categories, to concepts or theories. This is done by first 
encoding (i.e. writing words or phrases that describe paragraphs or even smaller sec- 
tions of the data material) the data in a manner that retains the details of the original 
material. The next step is to systematize the codes that are relevant to the research 
question into categories. Finally, concepts are developed by applying relevant theory to 
the categories. 

To increase the validity of our research, two of the researchers that created the codes 
first carried out the data coding individually. The data from the first round of the data 
collection resulted in 383 codes, and the second round gave 231 codes. The “NVivo 12 
Pro”-software was used in the coding process. After the coding, the researchers created 
inductive categories based on the codes. This resulted in 21 categories for the first 
round and 12 categories for the second. By applying the MST lens, the findings were 
organized into two main categories, production structure and control structure. Com- 
bined, these categories provide insight on the dependencies occurring with agile teams 
in complex organizations. The purpose of the two last rounds of data collection was to 
saturate the categories. Feedback sessions were used to present the intermediary results 
to the case. 


Table 1. Collected data 


Data sources Participants 


25 interviews Head of AP, IT managers, business managers, business architect, POs, IT 
developers, IT analysts and business developers 


4 observations Management group meeting and retrospective (2), PO meeting and 
retrospective, and a team retrospective 


2 feedback Head of AP and business manager, AP’s management group 
sessions 


4 Findings 


Production Structure: AP has dependencies to its surrounding non-agile organiza- 
tion, thus resulting in a complex production structure. The dependencies are in relation 
to the IT and business units in NorBank, as well as personnel working on core and 
business systems on which AP systems rely. 

AP’s dependency towards the IT-side of the organization proved particularly chal- 
lenging, as AP uses shared IT-resources. While IT-resources work in AP, they also have 
tasks in other projects and in their own units. When one PO is asked about the effects of 
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having shared resources, the answer is: “Having resources that aren’t 100% (dedicated) 
is clearly a challenge. [...] If they have line tasks, then their mind is on that and not the 
project (AP), it is something we have to work with. ” A team member in AP also reflects 
this diverging focus: “I work 50%, 50%, 40% (distributed between AP, department and 
another project). [ ...] It’s chaotic working with so much at the same time. [...] You don’t 
feel like you get to do your job satisfactorily.” AP’s dependency towards the 
IT-departments through shared resources gives rise to structurally conditioned distur- 
bances. A PO illustrates this disturbance: “Often there is something that, ‘we just have to 
fix tomorrow’ or customer issue or that kind of thing that is prioritized over everything 
else. The consequence is that you get fewer resources in the flows (AP teams).” 

AP develops software solutions meant for business-to-business units of NorBank, 
such as sales and customer service. The business side knows the customer, and is 
sometimes the customer of the solutions developed by AP. AP needs to mobilize 
resources from the business side to understand the software’s functional requirements. 
A PO describes this process: “When we start developing a new module, we assess who 
is to be included in a workgroup (from the business side), lead by one of our (the 
teams’) business developers. We have to fetch those who are on the phone with cus- 
tomers.” A manager from the business side indicates that such work is not always 
prioritized: “Many (POs) wish that more (from the business side) were hands-on and 
involved. [...] But we are not there that it is prioritized.” 

There are also dependencies to personnel with knowledge and responsibility for the 
core and business systems. These systems constitute the underlying IT-infrastructure, 
on which business systems are built. A PO indicates how this can be time-consuming: 
“This takes time. [...] We, together with [a core team], develop [a new system], but 
you also have those who work with the business systems. [...] They have completely 
different prioritizations. ” 

In sum, AP’s production structure has many dependencies to the surrounding 
organization, which as shown have diverging prioritizations. This creates disturbances 
that influence the AP-teams’ ability to be autonomous and agile. Thus, the production 
structure gives rise to challenges regarding who controls the resources. 


Control Structure: AP’s control structure functions so that AP teams, through their 
respective POs, have a regulatory potential that is internally high, and externally low, 
as illustrated below. 

The POs have a high regulatory potential internally through trust from the man- 
agement group. Due to the dedication of internal decision-making authority to POs, the 
AP-teams have adapted their work methods and a coordination layer within the AP has 
been removed. An IT-manager describes trust as an important factor: “T think it’s an 
important factor for the teams and those leading the teams that we [the management 
group] give them trust, in regards to us being confident that they work with the right 
stuff.” One of the POs also expresses this trust: “I feel that we are very autonomous in 
the team. If we want to do it this way or that way, it’s just up to us to decide it.” 

Externally, on the other hand, the POs are responsible for handling several 
dependencies. When asked about the POs negotiation power and understanding of the 
surrounding organization, a manager from the business side answers: “Jt is a very 
important factor. [...] You are supposed to deliver something to many (stakeholders). 
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Or, a lot of people that care. The maneuvering of the stakeholder map, in that way, is 
demanding.” The low external regulatory potential is indicated by the fact that the POs 
themselves do not have control over the resource allocation from the IT side, the 
priorities of the business side, and resources in core and business systems. A PO 
illustrates the lack of control over resource allocation from the IT side: “The only thing 
I can’t do anything about is the team members and how many percent they are 
allocated to the team. That is, in a way, beyond my control.” Another PO describes 
how this takes time: “The project took a lot of time last year before we had any 
progress because we were staffed wrong.” An extra dimension to the team challenge 
with shared resources, is that the employees are highly autonomous in their work 
prioritization, as one IT-analyst confirms when asked about who decides where work 
should be done: “There is nothing given at all. [...] I decide myself.” The above 
illustrates how POs need to handle both IT-managers and —resources in AP’s depen- 
dency to IT units. 

A PO describes how the dependency towards the business side and their prioriti- 
zation cause disturbances hindering the AP-teams’ effectiveness: “Jf you meet a 
service-minded person, like we did when needing [type of insurance], it is done ‘in 
seconds’. And if you meet someone different, like we did [another type of insurance], it 
takes like a month.” 

The dependency on core and business systems personnel is also a hindrance, 
according to one PO: “What also limits our effectiveness is unstable test systems. [...] 
the test systems were down for 1,5 week. [...] I felt that no one listened when I brought 
it up.” 

In sum, the above indicates how the control structure does not give enough external 
regulatory potential to enable handling of disturbances. Thus, the control structure does 
not align with the complex production structure. 


5 Discussion 


Extant research shows that there are challenges related to dependencies between agile 
autonomous teams and a surrounding complex organization [1, 7]. However, empirical 
insight on the particularities of these challenges is scarce. Driven by our research 
question - how is complexity in organizations influencing the autonomy of agile teams 
— we have reported findings from an empirical case study of a bank that has established 
an agile program consisting of autonomous cross-functional teams within a complex 
organizational setting. Our findings indicate how production structure and control 
structure influence the autonomy of teams. We find how the AP has a high degree of 
internal regulatory potential (i.e. shaping the inner life of the program), while the 
external regulatory potential is lower (e.g. regulating access to resources). These 
findings contribute to the existing literature on agile autonomous teams in complex 
organizations as we discuss. 
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First, in terms of production structure, we find that not all production resources are 
embedded in the AP, which leads to a reliance on shared resources. This creates 
external dependencies, which we find are time-consuming to handle and hence reduce 
the autonomy of teams. This adds to the findings from [7], as a form of negotiation that 
takes place between autonomous teams and the surrounding organization. While 
having full-time resources dedicated to teams is common in many organizations, we 
expect that having shared production resources with many dependencies is more 
common in complex organizations adopting agile methods. MST [10] suggests 
reducing such dependencies by organizational redesign moving more resources that are 
full-time into the autonomous teams. Such redesign of organizational structures is also 
what Dikert et al. [3] suggest. Changing the surrounding organizational structure to fit 
agile, is somewhat different from Barlow et al. [2], who suggest tailoring methods 
depending on the size of the project and the nature of the dependencies. We cannot 
conclude on what is the best course of action, if there exists one, but illustrate how 
there are different ways of approaching the challenges of dependencies. 

Second, we find that AP has a high level of internal regulatory potential by having 
sufficient levels of control of the inner workings of the agile program, such as how 
work is organized, what tasks that are prioritized etc. However, the dependence on 
resources that are outside of AP, such as shared IT resources, lowers the external 
regulatory potential. Low external regulatory potential, our findings show, is time- 
consuming and limits the autonomy of the teams in AP. This is in line with other 
research on how plan based and waterfall managed surroundings is a restricting factor 
upon interfacing agile teams [8]. Some suggest that it is necessary that all departments 
transform towards agile if one is to gain the full benefits [3]. An additional insight from 
MST [10] is that the degree to which external dependencies influence autonomous 
teams’ production capacity is dependent on the level of control the teams have in terms 
of regulating disturbances. With shared resources, control, i.e. the ability to regulate 
potential disturbances, may well be, at least partially, outside the agile autonomous 
teams’ control, and potentially influence production capacity. 

Finally, there are also some practical implications we can draw from our analysis. 
First, according to MST [10], creating such agile programs should start by creating a 
production structure with as few dependencies as possible. One way to do this is to, as 
far as possible without negative consequences to the rest of the organization, staff the 
agile programs with full-time resources. Second, if the organization cannot provide 
full-time resources into agile programs, it would be beneficial if the units having 
resources in the program also use agile ways of working. Then the shift from working 
in the agile program and the units will be less time-consuming. Third, resources 
working on core systems often become bottlenecks and create time-consuming 
dependencies. One way to remedy this would be to aim to give a sufficient level of 
resources experience and training in such systems. This involves giving developers 
enough time to develop in-depth knowledge of core systems. 
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6 Conclusion and Recommendations for Future Work 


In this paper, we have analyzed the establishment of agile autonomous teams in a 
complex organization. A perspective on the alignment of production and control 
structure relating to dependencies and disturbances can provide new insights on agile 
team autonomy in complex organizations. First, it would be interesting to investigate 
the alignment of production and control structures in organizations that have done 
full-scale agile transformations, that is, moved towards fully autonomous teams. Such 
studies could be used for comparison towards cases where only parts are transformed, 
as reported in this case. Second, we have only begun to describe the role of production 
and control structures relating to agile autonomous teams in complex organizations, so 
there is a need for more in-depth studies to flesh out this phenomenon. Third, in our 
analysis, part-time resources is a prime source of disturbances. However, it will be 
necessary to investigate other sources of disturbances, such as technical dependencies, 
and see how they can be controlled. Finally, it seems relevant to investigate the level of 
control necessary for teams in order to regulate disturbances and be able to act 
autonomously. 
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Abstract. This paper presents a model to assess team autonomy developed and 
deployed in a South African bank’s IT department. The bank has been 
deploying SAFe® for the last two years and in the process has increased sig- 
nificantly the number of software releases. Historically, the teams had to obtain 
multiple levels of authorization prior to a release but this level of governance 
and control was contradictory to the principle of team empowerment at the core 
of agile approaches. The model is inspired from the theme of a pilot’s ability to 
fly an aircraft using five levels. The level is determined based on team fly-ability 
and elevation safety described in detail in this paper. Team fly-ability includes 
two elements: (1) maturity of engineering practices and (2) the ability to manage 
traceability and risk through ease of recovery. Elevation Safety is based on two 
components: (1) historical data on deployment performance and severity of 
incidents and (2) the application dynamics and criticality. The main benefits of 
this program are improved accountability of teams, reduced approval time, and 
reduced attempts to find workarounds and loopholes. 


Keywords: Scaling agile - Team autonomy - Deployment > Governance 


1 Introduction 


More and more large organizations are now adopting agile enterprise-wide. However, 
the scaling of agile to a larger undertaking, creates an entire new set of problems and 
challenges ranging from resistance to change to the problems associated with hierar- 
chical management and organizational boundaries. Leffingwell [1] groups the chal- 
lenges of scaling agile into two broad categories: (1) those inherent to the methods 
themselves, “because of the fixed rule bases and assumptions built into the methods” 
(p. 87); and (2) challenges imposed by the enterprise that “will prevent the successful 
application of the new methods” (p. 87). More recently, Dikert, Paasivaara and 
Lassenius [2] surveyed 52 publications describing 42 industrial cases and reported 35 
challenges grouped in nine categories: change resistance, lack of investment, agile 
difficult to implement, coordination challenged in multi-team environment, different 
approaches emerge in a multi-team environment, hierarchical management and orga- 
nizational boundaries, requirement engineering challenges, quality assurance chal- 
lenges, integrating non-development functions. Surprisingly, very little empirical 
research has been done on how to alleviate these challenges [3]. 
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However, consultancy firms have developed various frameworks and models to 
address these challenges to implement scaled agile: Disciplined Agile Framework [4], 
Large Scale Scrum (LeSS) [5] and Nexus [6]. The most popular framework for scaling 
agile remains SAFe [6-8]. 

All these frameworks are building on the values and principles of the agile man- 
ifesto [9], among others the deployment and support of self-organized teams. Although 
much has been researched on teams, particularly in the field of psychology, much 
remains to be investigated in the context of agile deployment. The objective of this 
paper is therefore to contribute to the field, based on a research question proposed, 
during last year’s workshop on scaling agile at XP 2018 [10]: “What is the right degree 
of team autonomy in different contexts (and how to measure it)?” 


2 Literature Review 


Parker, Holesgrove, and Pathak [11] define a self-organized team “as a self-regulated, 
semi-autonomous small group of employees whose members determine, plan and 
manage their day-to-day activities and duties under reduced or no supervision.” 
(p. 112) and the labels “autonomous teams” have been used as synonyms for “self- 
organizing teams,” “self-managing teams” and “empowered teams” [10]. 

Teams have been studied for decades, primarily in the field of psychology. Liter- 
ature abounds on numerous topics such as: leadership, roles, phases, performance, team 
dynamics, etc. More and more researchers reuse some of that literature to study soft- 
ware development teams using agile approaches, for example to relate autonomy to 
team performance [12], empowerment and outcomes in software development orga- 
nizations [13], productivity of self-organized teams [11] and job satisfaction and/or 
motivation [14]. 

However, according to Kakar [15] “no approach or instrument has yet been 
designed to measure and compare self-organization between teams. Second, although 
conceptually the difference in adoption of self-organization in agile versus plan-driven 
methods has been discussed previously in the literature, the levels of self-organization 
between these two major paradigms of software development have not been objectively 
compared” (p. 208). In the case presented in this paper, the issue was the assessment of 
the teams and the level of authority delegated to them by the senior management. This 
is what Cao, Mohan, Xu and Ramesh classified as “sources of structure” in their 
proposed framework. 


3 Methodology 


The development and deployment of a new model to assess teams in order to grant 
them the right level of autonomy to release software was observed in a large South 
African bank’s IT department. Twenty employees in the department were interviewed. 
The interviews were conducted by the two researchers themselves. The twenty inter- 
viewees comprised of four people from business who were direct customers of IT and 
ultimately the agile process, two people from the agile portfolio office, four portfolio 
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project managers, the CFO of the IT department, two CIOs within the IT department, 
three release train engineers, one COO and three agile coaches. 

Most of the interviews were directed towards understanding the link between the IT 
initiatives and the organization’s strategy. However, during the course of the research 
many interviewees kept referring to an internal program to assess a team’s autonomy 
with respect to the deployment of software. There were two interviews with the people 
responsible for the deployment and improvement of engineering practices. The inter- 
views were coded in ATLAS.ti to assist in the analysis and summary of the approach. 
The objective of this paper is primarily to present and share an experience report from 
the perspective of the bank with the understanding that their approach might be of 
interest to other organizations. 


4 Case Description 


SA Bank (Note: This is a fictitious name to protect the identity of the bank), a financial 
institution, is one of the largest African financial institutions by assets. SA Bank is 
among the largest organizations in South Africa by market capitalization. It offers a 
wide range of banking and financial services to millions of personal customers in 20 
African countries. The company employs over 6000 people in their IT. 

SA Bank decided to start deploying agile practices in their IT department. They 
redesigned their software development completely and restructured around self- 
organizing teams responsible for products rather than specific activities. These teams 
would also be in close contact with business representatives and would be entirely 
responsible for the development, testing, deployment, and maintenance of their prod- 
ucts. The intention was to reduce the number of handoffs and simplify the development 
process dramatically. The SAFe deployment was strongly committed to and supported 
by executives and line managers across the board. 

At the time of the interviews, SA Bank had deployed SAFe 4.5 but used only three 
of the four layers [8, 16]: They did not use the “large solution” layer but had the 
intention to deploy it in coming months. 

Semi-permanent self-organizing agile development teams were put in place to 
support the planning, prioritization, harmonization, synchronization, development and 
release of the features/systems. The term “semi-permanent” is used to refer to teams 
being maintained as permanent as possible with the exception of changes related to 
turnover, punctual member swaps due to competence requirements, etc. The agile 
teams use many of the Scrum tools and artefacts such as backlogs, burn-down charts 
and Kanban walls. 


5 Background Leading to the Introduction of Earn Your 
Wings 


An incident in March 2017 triggered the introduction of the “Earn Your Wings” 
program. The teams were used to systematically obtain authorization to release soft- 
ware from a committee, composed of senior managers, called the change advisory 
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board (CAB). One of the teams wanted to deploy a change into production. The 
changes would have been deployed using a fully automated pipeline and the team was 
convinced that the software would not be faulted. That release happened to occur in a 
high-care period. This meant that the team required authorizations from the production 
manager, from the business responsible, then from the area senior management head 
sign-off and then finally a sign-off from the CAB. 

One of the people responsible for process improvement and SAFe deployment 
started to challenge the governance and approval process. How could they be talking 
about team autonomy and team self-organization while at the same time imposing a 
very cumbersome approval process? 

After a number of focus groups, interviews and surveys, they realized that this old 
approval process actually had three negative side effects (what they called reverse 
incentive behaviors): 


1. The CAB was shielding people from consequence management. If a team was 
deploying a change into production, so long as they received CAB sign-off, they felt 
relieved from taking responsibility if anything went wrong. 

2. The second reverse incentive was low-low changes. Only low impact and low risk 
changes were self-governed. If changes were categorized as low-low, the teams did 
not have to go to CAB. Consequently, more and more teams were categorizing 
everything as low-low with the risk of deploying faulty high-risk/high-impact 
packages. 

3. If the approval process is tedious, teams tend to package the release in larger 
bundles and decrease the release frequency 


6 Earn Your Wings 


In order to reverse these negative side effects, the team in charge of improving the 
deployment process at SA Bank derived a detailed evaluating and rating scheme. This 
section summarizes what the bank representatives presented to the researchers. They 
used the theme of a pilot’s ability to fly an aircraft using five levels, from lowest to 
highest: 


e Level 1 Red Bull: This is the lowest level for which the highest level of autho- 
rization is required. This comes from the image that “Red Bull gives you wings” but 
actually you are not really able to fly. In other words, the team (and the supported 
software) is at the lowest level of autonomy. 

e Level 2 Hot Air Balloon: Although you can get into the air, you are reliant on fire, 
which can easily go up in flames. You are restricted by conditions as to whether it 
can take off or not. You carry very little safety gear. 

e Level 3 Small helicopter: You have freedom of movement but with extra caution. 
Individually you decide if this is trusted and if the risk is worth taking. Although 
you can get somewhere, with relative ease, you do not have the best safety gear if 
something goes wrong 
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e Level 4 Dinky Plane: While you have the freedom to go wherever you want, there 
are situations in which you would choose not to fly. A trusted form of transport, 
with a little extra convincing 

e Level 5 Private Plane (highest): Freedom to go wherever you want, whenever you 
want. The most trusted form of transport. Air traffic control simply coordinates but 
does not question. 


The level is determined based on Team Fly-ability and Elevation Safety described 
in detail in this section. 


6.1 Team Fly-Ability 


Team fly-ability includes two elements “Maturity of engineering practices” (60%) and 
“Ability to manage traceability and risk through ease of recovery” (40%). 


Maturity of Engineering Practice 

The teams subjectively assess their own level of Maturity of Engineering Practices 
based on: the level of automation, the level of testing, the size of work package and an 
assessment to whether acceptance criteria are met. In practice, this is performed 
through a tool called Continuum using elements such as coding practices, continuous 
integration, incident management, release management, quality assurance and risk 
management. If teams decide to overrate themselves, they take on the risk of something 
going wrong. 


Ease of Recovery 

The ease of recovery evaluates the ability to manage traceability and risk, the time to 
recover and the ability to roll back and restore. This is assessed, using a tool called 
Remedy, based on the Mean Time to Recover. The objective is to maintain the down 
time under the agreed levels contracted in the Service Level Agreements. 


6.2 Elevation Safety 


Elevation Safety is based 100% on historic data on deployment performance and 
severity of incidents with some consideration of the application dynamics and criti- 
cality being taken into account. 


Historic Data on Deployment Performance and Severity of Incidents 

This is based on the performance of the previous five deployments answering questions 
such as: Have you caused incidents within the two weeks after your deployment due to 
the change? Have you had an avoidable production incident? What was the frequency 
of deployments? 


Application Dynamics and Criticality 

This is based on the chief information officer (CIO)’s list of the most critical appli- 
cations with respect to: number of users, rate of change, number of dependent systems, 
the number of countries impacted. 
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6.3 Overall Assessment on a Scale of Five Levels 


Using the combination of team fly-ability and elevation safety described in the previous 
sections, the overall level of autonomy (from Red Bull to Private Plane) is assessed 
using the grid in Fig. 1. 


1 2 
Elevation Safety 


Fig. 1. Overall assessment of the team autonomy 


The wings are assigned to teams, not individuals. The teams are continually 
assessed using real-time data (for example on the quality of their prior releases). 


6.4 Authorizations Required to Deploy 


The release and deployment authorizations required, depends on the level of the team 
as follows. This varies from required authorization of the CAB for all changes, for 
Level 1 (Red Bull), to complete autonomy for releasing and deployment at Level 5 
(Private plane). In the case of level 5, the CAB would just be informed and would not 
be involved in the decision. There are various degrees of authorizations required for 
intermediate team level medium or above. Depending on the level, the release and 
deployment constraints are specified e.g. ability to release during the freeze periods, 
time of the day when deployment is allowed, frequency of deployment (per week), 
artefacts required. 
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7 Conclusion 


At the time of the interviews, 70 teams had “earned their wings.” The objective was to 
deploy to approximately 300 teams. Consequently, the organization was working on 
the improvement of engineering practices to support teams. They also continued to 
automate data collection to support team evaluation. As far as the SA Bank was 
concerned, the main benefits of this program had been: (1) Improved accountability of 
teams (2) reduced duration of the CAB (3) reduced attempts to find workarounds and 
loopholes and (4) coordination done at the right level i.e. teams govern each other as 
opposed to management doing it. Release management does not question the releases; 
they just make sure that there is no mid-air collisions (like air traffic controllers). 

Although this research is based on a limited set of interviews, the authors wanted to 
share how SA bank had used an objective assessment of the autonomy and maturity of 
the teams as a good example of how an organization tried to answer the research 
question, “What is the right degree of team autonomy in different contexts (and how to 
measure it)?” Their objective, in doing so, was to improve the deployment process both 
in terms of quality and the time required to approve the releases. 
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Abstract. This workshop explored the main research challenges in con- 
ducting agile software development in large-scale software development. 
We considered multi-site companies with projects that include a large 
number of teams which develop sophisticated systems by adopting and 
using agile methods. Such topics include inter-team coordination, knowl- 
edge sharing, agile transformations, and project management models 
that facilitate multiple cooperating self-organising teams. The keynote 
talk, by Darja Smite, provided empirical results on communities of prac- 
tice within the music streaming service Spotify. We accepted five full 
research papers which are included in this volume. These five papers 
report empirical research studies using surveys, observational and case 
studies. Workshop participants also worked together in groups to estab- 
lish current research topics and priorities. This workshop summary con- 
tributes a current snapshot of research along with future research agendas 
in the field of large-scale agile development. 


Keywords: Large-scale agile software development - Architecture - 
Portfolio management - Project management - Scaling - 
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Business agility - Knowledge sharing 


1 Introduction 


The goal of this workshop was to explore the main research challenges in conduct- 
ing large-scale software development programmes using agile methods. We con- 
ducted a half-day workshop during the XP conference in Montréal in May 2019. 
How to apply agile methods to large projects was identified as the “top burn- 
ing research question” by practitioners at XP2010 and has since then attracted 
increasing interest among practitioners and researchers. The first of this work- 
shop series was organized at XP2013. 

Agile software development methods are conventionally applied in small, co- 
located development teams. There is growing interest, from researchers and prac- 
titioners, in agile methods applied to large-scale projects which comprise multiple 
self-organising teams cooperating to develop sophisticated software systems. 
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This workshop addressed research challenges in large-scale agile development 
and identified topics such as inter-team coordination, large project organization, 
release planning and architecture and practices for scaling agile methods. 


2 IEEE Software Special 


The workshop followed a recent special issue on “Large-scale Agile” in IEEE 
Software [4]. The special issue, published in March/April 2019, comprised four 
papers. The first paper, explored the relationships between project size, agile 
practices, and successful software development [10]. Flexible scope, frequent 
deliveries to production, ability to tolerate a high degree of requirement changes 
and more competent providers appear to enable the success of agile approaches 
to development in large-scale projects. 

The second paper, investigated implementing large-scale agile frameworks 
[3]. A fifteen year collaborative study led to the researchers identifying nine 
challenges to large-scale agile transformations. Among the main challenges are: 
top-down versus bottom-up implementation, overemphasis on 100% framework 
adherence over value and lack of evidence-based use. 

The third paper, explored knowledge sharing in large-scale agile organizations 
[16]. Specifically, the guild model in the Spotify culture was examined. In Spotify, 
guilds are a recognised instantiation of the concept of communities of practice 
[19] implemented to promote collaboration among engineers across the company. 
This paper formed the basis of the keynote talk for the workshop reported here. 

Finally, the fourth paper, investigated product owner behaviours [1]. Prod- 
uct owners, in Scrum terminology, identify and prioritise requirements as well 
as approving finished software for release. However, on large scale projects, the 
scope of activities required goes beyond the capacity of one person. The notions 
of “area product owners” [15] or product owner teams [2] have previously been 
explored. The current study found that face-to-face interactions are preferred, 
when dealing with geographical, temporal, and cultural distances [1]. On projects 
regarded by practitioners as successful, product owners use their influencing skills 
to keep a wide range of stakeholders focused on a specific set of goals. Experi- 
enced product owners use a minimum viable product to create the capacity for 
change. The study suggests that the process of building a product owner team 
should be explicit and well defined. 


3 Workshop Contributions 


The workshop comprised a keynote talk, speakers selected following submission 
of short papers, which were peer-reviewed by members of the program commit- 
tee, and an interactive session to identify research topics and priorities. 
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3.1 Keynote 


The keynote talk, by Prof. Darja Smite from Blekinge Institute of Technology in 
Sweden [17], focused on Guild use within Spotify, the internet music streaming 
service, and was based on the recent article in IEEE Software [16]. Guilds are a 
social structure for stewarding knowledge or an explicit way to inculcate commu- 
nities of practice within the organisation. The research found that engagement in 
guilds, at Spotify, is cultivated through annual un-conferences, “Slack” channels 
and electronically-mediated opinion elicitation (requests for comments). 


3.2 Research Papers 


For the 2019 workshop we had seven submissions, of which five were accepted as 
full research paper presentations. The first paper “SAFe Adoptions in Finland: A 
Survey Research” reported benefits in terms of transparency, co-operation and 
cadence [12]. However, organisations adopting SAFe reported challenges with 
legacy organisational structures, lack of tailoring to their context and implemen- 
tation issues. The respondents reported that SAFe was being used in conjunc- 
tion with other agile practices. The authors also observed evidence of incomplete 
adoption of SAFe practices. 

The second paper, “Comparing Scaling Agile Frameworks Based on Underly- 
ing Practices” identifies several common practices among adopters of scaled agile 
frameworks [18]. The authors found that many scrum project and scaling prac- 
tices underpin the frameworks observed in their study. The authors present an 
interesting “subway map” diagram to illustrate practices used in several frame- 
works as compared with more esoteric practices. 

The third paper, “Finnish Large-Scale Agile Transformations: A Survey 
Study” is based on the same survey as the first paper [11]. In this third paper, 
the authors found that 44% of their survey respondents have completed an agile 
transformation at least one year prior to the survey. A further 30% of the respon- 
dents in the study are in the process of an agile transformation. The authors 
also discovered that 60% of the respondents in the study worked in organisa- 
tions that made use of external consultants or subcontractors in order to assist 
the change process. The authors suggest that organisations use consultants and 
subcontractors to provide new competencies and additional resources to perform 
transformations. 

The forth paper, “Changes Over Time in a Planned Inter-Team Coordina- 
tion Routine” investigates the Programme Increment (PI) Planning routine [9]. 
PI Planning is considered a fundamental practice within SAFe. The author con- 
ducted an observational study of PI Planning within three organisations and 
found differences in the approaches being taken. This study suggests that organ- 
isations are tailoring their SAFe PI Planning practices. 

Finally, the fifth paper “Technical-, Social- and Process Debt in Large-Scale 
Agile: an exploratory case-study” explores how using short-term expedient techni- 
cal or organisational constructs can make future change more difficult or expensive 
[13]. The research reveals that process debt is resolved by inter-team coordination, 
and that teams spend a lot of time discussing social debt in retrospectives. 
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3.3 Future Research Trends 


The workshop attendees were asked to work in four groups, each group address- 
ing one topic adapted from research priorities identified during the 2017 work- 
shop [14]. Thus, the four groups were considering: 


— Inter-team Communication, 

Agile Transformation, Business Agility, 
Knowledge Sharing, Knowledge Networks, and 
Scaling Agile. 


Each of the four groups considered important issues in each of the topics. Each 
group was then asked to prioritise the topics. The results of each group is pre- 
sented as a flip chart illustration, available online as follows: 


— Inter-team Communication [5], 

— Agile Transformation, Business Agility [6], 

— Knowledge Sharing, Knowledge Networks [7], and 
— Scaling Agile [8]. 


For inter-team coordination, the group emphasised the continuum of team 
alignment to strategy and autonomy along with new roles and new communica- 
tion modes enabled by new tools. For agile transformation and business agility, 
the group emphasised issues around measurement, budgeting and success as well 
as customer collaboration and agile framework evaluation. For knowledge sharing 
and knowledge networks, the group emphasised on-boarding new team members, 
finding competencies in the organisation and balancing knowledge sharing with 
focused work. Finally, for scaling agile the group emphasised public sector agile 
along with “how is agile visible (in mindset and results) to senior executives?” 
as well as issues of trust and transparency. 


4 Programme Committee 


Many thanks to the members of the programme committee many of whom have 
also contributed to previous workshops, as follows: 


— Steve Adolph, cPrime, Canada 

— Finn Olav Bjornson, NTNU, Norway 

— Torgeir Dingsøyr, Sintef, Norway 

— Jutta Eckstein, IT Communication, Germany 

— Peggy Gregory, UCLAN, UK 

— Tomas Gustavsson, Karlstad University, Sweden 
— Andy Haxby, Competa, Netherlands 

— Aymeric Hemon, Université de Nantes, France 
— Eric Knauss, Gothenburg University, Sweden 

— Maarit Laanti, Nitor, Finland 

— Carl Marnewick, University of Johannesburg, South Africa 
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— Nils Brede Moe, Sintef, Norway 

— Helena Holmstrom Olsson, Malmö University, Sweden 
— Maria Paasivaara, Aalto University, Finland 

— Yvan Petit, ESG UQAM, Canada 

— Alexander Poth, Volkswagen, Germany 

— Ken Power, Cisco, Ireland 

— Klaas-Jan Stol, Lero, Ireland 


Without the valuable support of these programme committee members the 
workshop would not have been possible. Thanks also to Rashina Hoda, the Work- 
shop Chair for XP 2019, who enabled the workshop within the XP conference 
framework. 


5 Conclusions 


This workshop successfully created an opportunity for researchers and practi- 
tioners to consider the latest trends in large-scale agile development. The papers 
in these proceedings, the keynote and interactive session contribute a snapshot 
of the start-ofthe-art in this field. The authors presented evidence of frame- 
works being used to enable agile transformations in organisations, but also of 
incomplete adoption of frameworks and commonalities between practices being 
used in frameworks. 
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Abstract. Scaled Agile Framework (SAFe) was released in the year 2011. 
Since then it has become the most popular agile scaling framework in use. In 
this paper we examine the benefits and obstacles of SAFe adoptions in Finland. 
The data is based on a survey we conducted in Finland in 2018, when many 
respondents had already been following SAFe for some years. The biggest 
benefits reported are transparency, co-operation, and cadence. The biggest 
obstacles are the old organizational culture, that the SAFe model has not been 
fitted to the organization and implementation problems. The results indicate that 
although many respondents of the survey (80%) use SAFe, they are still 
struggling with their agile transformation, while using a mix of old and new 
methods and only a subset of the SAFe practices. 


Keywords: Scaled Agile Framework - SAFe - Agile transformation - 
Large-scale agile - Scaled Agile - Agile 


1 Introduction and Background 


Scaled Agile Framework (SAFe) was launched in the 2011 Agile conference [1]. Since 
then it has become the dominant agile scaling model in large enterprises [2]. According 
to the 12th State of Agile Report conducted by Version One and Collabnet, SAFe is 
now the most widely adopted large-scale agile framework with the usage rate of 29% 
[3]. Scaled Agile Inc. has announced that there are 300,000 SAFe-certified practitioners 
in 110 countries, and that 70% of Fortune 100 companies employ SAFe-certified 
professionals [4]. 

Both benefits and challenges of SAFe adoptions have been reported. However, 
more empirical research is needed to understand how to adopt established frameworks 
like SAFe, how are they used and tailored, and what their benefits and challenges are 
under different circumstances [5, 6]. This paper examines SAFe usage, benefits, and 
obstacles in organizations in Finland to contribute to those research gaps. 

In general industrial experiences report a 10-50% improvement in employee 
motivation, 30-75% faster time-to-market, 20-50% increase in productivity, and 25- 
75% reduction in defects [4] — but empirical research validating these results are 
missing. In 2017 the Large-Scale Agile Workshop called for more research on scaling 
agile along with inter-team coordination, knowledge sharing and knowledge networks, 
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agile transformation and business agility [5]. This raises numerous questions, like is 
SAFe used alone, or together with other agile methods? What kind of results do the 
companies get with it? 

The existing research on SAFe cover for example SAFe and Portfolio Management 
[7-9], SAFe and testing [10], SAFe in distributed settings [11], maturity model for 
adoptions [12-14], principles of large-scale agile [15], case studies of adoption [16, 
17], comparison of different scaling frameworks [18], and reported benefits and chal- 
lenges [6]. However, there is lack of empirical research on SAFe adoptions and usage 
in companies. With this paper we are aiming to fill in the gap with a survey research 
into SAFe adoption across multiple industries and companies. 


2 Survey Research Design 


The purpose of our survey research was to examine the current state of Agile in 
Finland. Agile has previously been surveyed in many different investigations, but 
currently in particular the rapid advances of digitalization make it especially topical for 
different organizations — not limited to software companies. 

Our questionnaire was composed starting from our selected main themes of 
interests including SAFe usage and transformations. The specific questions were then 
compiled by referring to prior surveys for comparison purposes (e.g., [20]) and by 
deriving from our industrial experiences. The target audience was intentionally not 
limited to software companies since we were also interested in non-software companies 
currently facing digitalization and becoming more software-intensive. The draft 
questionnaire was first piloted both in our industrial and academic organizations. The 
final version consisted of 50 questions with some variable parts depending on the 
selector questions. Especially the questions “What have been the three most significant 
benefits of the SAFe adoption?” and “What have been the three biggest obstacles to the 
SAFe transformation (adoption)?” were only presented to those respondents who stated 
they are using SAFe. 

The survey was implemented as a web-based online questionnaire. The question- 
naire was distributed social media and a proprietary industrial mailing list mass post- 
ings to over 600 people, and it was open for responding for four weeks during 
November and December in 2018. 


3 Results 


We received 136 responses to our survey, out of which 111 respondents (80%) were 
using SAFe. In this paper “SAFe users” refer to all respondents that replied to the multi 
choice question “What agile methods and models are there in use in Your company?” 
with the choice ‘Scaled Agile Framework (SAFe)’. Part of this group also used Scrum 
and Kanban and other methods. “Non-SAFe users” refer to the respondents stating they 
were not using SAFe. This is because the aim was to study differences between these 
two groups. Also there was no significant difference detected what comes to the length 
of agile methods adoption between SAFe and non-SAFe users. 
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The majority of respondents were using agile methods (“How widely does Your 
company use agile methods in software development?”) either for their entire orga- 
nization (20%) or for the entire business unit (59%); see Fig. 1. The result is in line 
with SAFe targeted to be the operational model for the entire company. Yet the further 
analysis of results reveals that there is no significant difference between SAFe users and 
non-SAFe users in this respect. In fact, it seems that many respondents use multiple 
methods mixed together. 90% of all SAFe users used also Scrum, and 83% Kanban, 
12% XP, 12% own model, 9% LeSS and 2% DAD. Only 5% of all SAFe users (6 
respondents) responded that SAFe is the only agile method they use. 
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entire company of our organization projects 
(e.g., business unit) 


Fig. 1. Most respondents use agile methods in entire company or in parts of the organization. 
Legend shows number of respondents (multiple choices allowed). 


Figure 2 presents the SAFe practices the respondents use. Not all respondents 
responded to this free text question. 


PO Sync Mi 42 
Scrum of Scrums Biadap 55 
ART Sync Biede 22 
Feature-teams Bimba 32 
Scaled DevOps Meimmm 22 
Architectural Runway pone 25 
Solution Demo Beia 37 E SAFe is only method 
System Demo feme 62 E all SAFe users 
Inspect & adapt Wikang 20 
Pi Objecuves Mim 3 
Program Increment {P1} -planning E A 70 
{Lean} Portfolio Management (Portfolio Level) jee eed 32 
Release Train, Solution Train LEA 67 


0 10 20 30 40 so 60 70 20 


Fig. 2. Number of SAFe practices used by those respondents who use SAFe. 
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With the scale from 0-100 most of the respondents (96 replies) thought that SAFe 
as useful, with the average of 65,78; see Table 1. 


Table 1. Statistical analysis of the responses to the question about the usefulness of SAFe with 
the scale from 0-100. 


N EOS X STDEV X ERRORX 95% INTERVAL 
96 9 "65,78 20,68 2,22 61,44-70,13 


47 respondents out of 111 SAFe users responded to the question about the most 
significant benefits of SAFe usage. The question was an open text question asking for 
the three biggest benefits. The three biggest benefits reported were (1) transparency 
(24) (2) co-operation (10) and (3) common cadence or rhythm (9). The coded (original 
answering data partially in Finnish) results are presented in Fig. 4. 


ne AEN 24 
EE co-operation, 10 
cadence, rythm, 9 
EEE, speed, getting faster, 5 
"n learning, continuous 
improvement, 5 
so planned way of doing, 4 
WN systematic way of working, 4 


WEEE common way of working, 4 


— framework that supports 
team, 3 


WEEE prioritization , 3 
EE communication, 3 
WE better predictability , 3 
WEEE coordination, 3 


WEEE handling dependencies , 2 

jms lle portfolio management, 
2 

WEEE good framework, 2 


WE scaling agility, 2 

WEE employee satisfaction , 2 
WE non-disturbancy, 2 
WE better produced value, 2 


WE work splitting, 2 

— removal of management 
waste, 2 

WR work estimation, 2 


0 5 10 1s 20 2s 30 
Fig. 3. Result of analysis of open questions of SAFe adoption benefits. 


51 respondents out of 111 SAFe users responded to the open text question to name 
three biggest problems on SAFe adoption. The biggest problems reported were (1) old 
mindset and culture (14 answers), (2) the model has not correctly fitted to own organi- 
zation (8 answers) (3) missing fluency when using the model (8 answers) and (4) lead- 
ership (7 answers). Figure 3 represents a coding summary of these open answers. 
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Fig. 4. Answers to three biggest problems in SAFe adoption analyzed. 


4 Discussion and Conclusion 


The purpose of our research was to study the state of SAFe adoption in companies in 
Finland. Yet, because of the anonymous nature of the survey we do not know exactly 
how many companies were represented by these answers. The respondents represented 
widely different industries though, and not just software or IT industries. 

The results indicate that although SAFe is widely in use (80% respondents), it has 
not in most cases replaced other methods and old practices, but is used together with 
those methods and practices. Only 5% of respondents stated that they are using SAFe 
as the only method. Most likely these could be e.g. subcontractors that work only with 
SAFe. The most commonly received benefit received with SAFe is transparency. The 
conclusion is, that although methodologist discuss hectically of the pros and cons of 
different models, most organizations use a combination of these methods. 

Transparency is usually just the first benefit of SAFe transformation that is received 
when organizations have implemented backlogs. SAFe is also being used without using 
all the SAFe practices; e.g. only 20% replied that they use DevOps with SAFe. We 
though received feedback that the term Scaled DevOps used specifically as the choice 
in this question caused confusion amongst the respondents — thus the real number of 
DevOps users could be higher than indicated by responses. 

The conclusion is that although many respondents stated they were using SAFe, it 
seems that most organizations are still at the beginning of their agile transformation. 
The benefits that SAFe lists got also mentioned but less often (see Fig. 4): execution 
speed was 4th mentioned benefit (5 notes) Value and employee satisfaction were both 
mentioned only 2 times, but improved quality was not listed as a benefit. 

We hope to conduct a longitudinal study in this area and see if the responses change 
over time. We also hope to get more results on what are the reasons behind successful 
and non-successful agile transformations. We also hope that we can repeat a similar 
study in Sweden and compare those results to these in Finland reported here. 
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Abstract. Context: Agile software development is widely-used by small teams 
and has benefits like increased transparency or faster feedback. However, 
companies want to benefit from Agile also in the development of big products, 
where multiple teams are involved. Many Scaling Agile Frameworks exist, but 
only few can be found in industry, especially SAFe, LeSS, and Nexus. 
Objective: The aim of this work is to identify commonalities of existing Scaling 
Agile Frameworks concerning their practices. Method: We extracted and con- 
solidated the practices of twelve frameworks and compared the frameworks 
based on their practices using a visualization. Results: Frameworks prescribe 
scaling practices as well as practices on team level. There are practices common 
to most frameworks like the scaled Scrum events, e.g., a scaled planning 
meeting or retrospective. Conclusion: Practitioners are enabled to make 
informed decisions when choosing or tailoring their individual Scaling Agile 
Framework. 


Keywords: Agile development - Scaling agile - Scaling frameworks - 
Scaling practices + Framework comparison © Subway Map 


1 Introduction 


The rising popularity of agile software development is based on many benefits like 
managing changing priorities, increasing time to market or team moral [1]. Agile is 
composed of values, principles, and methods. Scrum [2] is the most used agile method 
across all organization types and sizes [1]. All these methods base on different Agile 
Practices, like Daily Stand-Up or Sprint [2]. However, Scrum and all other Agile 
Methods are not sufficient to achieve the desired benefits of all kinds of organizations 
regarding agile development. Especially for big projects or organizations, Agile 
Methods are not sufficient, since they were designed for small teams only. However, 
organizations with big teams also want to develop Agile. Therefore, several so-called 
Scaling Agile Frameworks increasingly came up in the last six years. The most famous 
ones according to [1] are the Scaled Agile Framework (SAFe) [3] and Scrum-of- 
Scrums [4]. For those commonly used frameworks, some experience reports and 
studies exist, especially for SAFe [4—6]. However, also less known ones like FAST 
Agile Scaled Technology (FAST) [7] or Recipes for Agile Governance (RAGE) [8] 
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exist. Scaling frameworks are based on practices on the technological and managerial 
level. These practices form the foundation for the implementation of all frameworks. 
Only [9] conducted a comparison on practice level so far and identified eight common 
scaling practices by comparing LeSS and SAFe. If Scaling Agile Frameworks were 
compared directly in related work, the comparison was along characteristics of the 
frameworks [10-12]. [13] compared eight Scaling Agile Frameworks on how IT 
governance is covered. In this work, we aim to identify the commonalities of Scaling 
Agile Frameworks concerning their defined practices. We used the twelve Scaling 
Agile Frameworks from [12] and updated the visualization [12]. To be able to conduct 
a comparison on practice level, we first extracted and consolidated all practices from 
these twelve Scaling Agile Frameworks. 


2 Overview Over Practices 


We went through the descriptions of each practice given by the frameworks. Based on 
these descriptions, we divided the practices into three groups: (1) practices that are only 
used on team level (cf. Table 1 that only displays the Scrum practices), (2) practices 
that are only used to scale agile (c.f. Table 2), and (3) practices that can be used for 
both — scaling agile and on team level (c.f. Table 3). Based on this classification, we 
created three different tables that provide an overview of the categories, subcategories, 
and related practices. Scaling Agile frameworks do not only define scaling practices, 
but also demand practices on team level. These coordination mechanisms for each team 
help to better align multiple teams. Table 1 only shows the Scrum practices, since they 
also appear in the Subway Map. Scrum is the most commonly used method [1]. It 
describes the management practices without prescribing technical practices [14]. Most 
scaling frameworks base on Scrum on team level. 


Table 1. Scrum practices used on team level 


Categories Subcategories | Practices 

Meeting types | Daily Stand- Daily Scrum, Daily Stand-Up, Weekly Scrum, Stand-Up 
Up Meeting, Daily Coordination Meeting 

Planning Sprint Iteration Planning, Sprint Planning Part 1, Sprint Planning 

Meeting Planning and Investigation, Phase Planning, Sprint Planning, 


Planning Session, FAST Meeting - Part 2: Marketplace in 
Open Space style, Kick-Off 


Backlog Product Backlog, Product Backlog, Tribe Product Backlog, Team 
Preparation Backlog Backlog 
Sprint Sprint Backlog, Iteration Backlog 
Backlog 
Backlog Backlog Grooming, Product Backlog Refinement, 
Refinement Backlog Decomposition, Backlog Prioritization, PBI 


Inspection (in Sprint), Look-ahead Planning 


(continued) 
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Table 1. (continued) 


Categories Subcategories | Practices 

Iterative Sprint Sprint, Synchronous Sprints, Iteration 
Procedure 

Lessons Retrospective Retrospective, Sprint Retrospective, Iteration 
Learned Retrospective, Team Retrospective 


Review/Demo __ | Review/Demo Sprint Review, Sprint Review Record, Iteration Review, 
Production Readiness Review, Light-Weight Milestone 
Review, FAST-Meeting - Part 1: Review (show and tell), 
Project Review 


Progress Definition of Definition of Done 
Activities Done 


On a scaled level (cf. Table 2), many practices on team level are adapted on a 
scaled level. Team level practices like the Scrum events were adapted for a scaled 
environment, e.g. by changing the participants of the events. Many frameworks also 
demand team level mechanisms, such as a Kanban board, Burn Charts or Release 
Planning activities, to be used in scaled projects. In addition, dedicated scaling prac- 
tices like the Architecture Release Train from SAFe help to align the work of teams. 


Table 2. Scaling practices 


Categories Subcategories Practices 
Meeting Scrum-of-Scrums Scrum-of-Scrums-Meeting, Scrum-of-Scrums, 
Types Nexus Daily Scrum, Cross-Team Coordination, 
Inter-Team Coordination Meeting 
Product Owner Product Owner Sync 
Sync 
Planning Scaled Planning Program Increment Planning, Sprint Planning Part 2, 
Meeting Nexus Sprint Planning, Portfolio Planning Meeting, 
Multisite Sprint Planning Part 1 
Scaled (Sprint) FAST Meeting - Part III: Announcements and 
Goal Alignment of Vision, Nexus Sprint Goal, Program 
Increment Objective, Terms of Reference, Agile 
Charter 
Backlog Scaled Backlog Program Backlog, Sync Backlog, Portfolio Backlog, 
Preparation Nexus Sprint Backlog 
Scaled Backlog Joint Light Product Backlog Refinement, Multisite 
Refinement Product Backlog Refinement, Portfolio Grooming 
Meeting 


(continued) 
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Table 2. (continued) 


Categories Subcategories Practices 
Manage Scaling Impediments (Backlog) 
Impediments Impediments 
Management 
Delivery Agile Release Agile Release Train, Release Train 
Train 
Architecture Architectural Architectural Runway 
Runway 
Open Source Collective Collective Ownership 
Data Ownership 


Release Release Planning Release Planning, Release Management, Release 
Activities Planning Meeting 
Release Handoffs Release Handoffs 
Release Review Release Review 
Lessons Scaled Joint Retrospective, Nexus Sprint Retrospective, 
Learned Retrospective Inspect & Adapt Workshop 
Review/Demo | Review/Demo Quality Assessment 
Scaled Review Overall Sprint Review, Multisite Sprint Review, 
Staging Readiness Review, Nexus Sprint Review, 
System Demo 
Progress Portfolio/Program Portfolio Kanban, Program Kanban 
Activities Kanban Board 
Others Initiative Assessment, Flex-Teaming, Beta Codex, 


Automated Metrics 


With Table 3, we show that there are also practices that are demanded on team 
level, but are also demanded under scaling conditions. This does not necessarily mean 
that the same framework demands a practice in both environments; it could also be that 
one framework uses the practice on team level, whereas another framework uses the 
practice as a scaling mechanism. General concepts like Time Boxing, Estimation or 
Open Source can be used by a single team as well as by multiple teams. User Stories 
help to describe the functionality of a product, independent of how many teams are 
responsible for this product. Communities of Practice are independent from projects. 
There are also practices that gain importance in a scaled environment, like Architecture 
or Release Activities. A focus on such topics is essential due to the increased coor- 
dination effort of multiple teams and the complexity of larger products. Likewise, 
Strategic Activities that can also already be applied on team level, support alignment of 
teams and reduce risk related to larger complex products. 
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Table 3. Practices for both scaled and team level 


Categories 


Meeting Types 


Subcategories 


Timeboxing 


Practices 


Timeboxing 


Planning Prioritization Prioritization Meeting, MoSCoW, Prioritized 
Meeting Requirements List 
Backlog Transition Evaluation Backlog, Transition Backlog, Practice 
Preparation Backlog Backlog 

Release Map Release Map 
Manage Manage Impediment Removal, Impediment Backlog, 
Impediments Impediments Continuous Impediment Removal 
Requirements User Stories, Portfolio Epic, Epic, Story Document, 
Documentation Requirement Document 
Community of Community of Practice 
Practice 
Iterative Increment Increment of Change, Integrated Increment, 
Procedure Evolutionary Development, Pre-and Post-Program 

Increment 

Architecture Architectural Architectural Envisioning 


Envisioning 


Open Source 
Data 


Internal Open 
Source 


Internal Open Source 


Release Delivery/Release Delivery/Release Plan 

Activities Plan 

Strategic Decision making Framework, Lean-Agile 
Activities Budgeting, Value Stream, Roadmap, Strategic 


Themes, Business Case, Decision Matrix, Funding 
Decision, Project Map 


Estimation 


Estimation, Forecasting 


Others 


Benefits Assessment 


3 Comparison of Frameworks 


We extended our “Subway Map” inspired visualization (similar to [15]) from [12] to 
show (1) which framework contains which practices as well as (2) which common 
practices are shared by multiple frameworks (cf. Figure 1). In the Subway Map (cf. 
Figure 1), each line represents a Scaling Agile Framework. The single subway stations 
illustrate the single practices that appear in those Scaling Agile Frameworks. We 
wanted the comparison to be easy to understand and visible at a glance. For the sake of 
simplicity, some subway stations represent only categories instead of single practices. 
The big stations symbolize practices that are used by many frameworks, e.g. Daily 
Stand-Up or Product Backlog. 

The Subway Map shows that some frameworks share common Scaling Practices 
like the scaled form of the Scrum practices, namely: Scaled (Sprint) Goal, Scaled 
Retrospective, Scaled Planning, Scaled Review, Scrum of Scrums, and Scaled Backlog. 
Whereas, some more individual practices only occur in few frameworks, such as, 
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Release Review, Program-/Portfolio Kanban Board, Agile Release Train, Beta Codex, 
and Architectural Runway. On a closer inspection, it can be seen that most of the 
widespread practices are based on Scrum. This can be explained by the fact that Scrum 
contains management practices that mainly serve to organize the process around the 
software development in a lightweight manner. 


Table 4. Practices and their occurrence over frameworks 


# Practice # Practice # | Practice 
11 | Sprint Planning 4 | Increment 1 | Manage Impediments 
11 | Sprint 4 | Scaled Review 1 | Scaling Impediments 
Management 
10 | Retrospective 4 | Strategic Activities 1 Architectural Runway 
10 | Review/“Demo” 4 | Estimation 1 Architecture 
Envisioning 
9 | Daily Stand-Up 3 | Agile Release Train 1 Internal Open Source 
8 | Product Backlog 3 | Release Planning 1 Delivery/Release Plan 
7 | Definition of Done 3 | Scaled Retrospective 1 Release Handoffs 
6 | Scrum of Scrums 2 | Prioritization 1 Product Deploy 
Validation 
6 | Sprint Backlog 2 | Transition Backlog 1 | Release Review 
6 | Backlog Refinement |2 | Scaled Backlog 1 Beta Codex 
Refinement 
5 | Scaled Planning 2 | Collective Ownership 1 Facilitated Workshop 
5 | Scaled (Sprint) Goal |2  Portfolio/Program 1 | Flex-Teaming 
Kanban Board 
5 | Requirements 1 Product Owner Sync 1 | Initiative Assessment 
Documentation 
4 |Scaled Backlog 1 Timeboxing 1 | Benefits Assessment 
4 |Community of 1 Release Map 
Practice 


Technical practices like Pair Programming are rather seldom part of scaling 
frameworks, since they often do not scale beyond software development on team level. 
Furthermore, it can be seen that all Scaling Agile Frameworks include scaling practices, 
but also non-scaling practices, namely practices on team level. Table 4 lists the prac- 
tices across the frameworks ordered by occurrence. With the help of Table 4 and our 
visualization, it also can be seen that the Scrum practices, which are only used on team 
level, are still applied by almost every framework. This obvious commonality across 
the frameworks was the reason to include the Scrum practices in the visualization, 
though they are team level practices. Sprints and sprint planning are the practices 
recommended by almost all frameworks. 
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4 Implications 


If practitioners have to decide on a suitable Scaling Agile Framework, they first need to 
know what frameworks exist. With the list of frameworks that are considered in our 
comparison, practitioners understand that there are more possibilities than the well- 
known frameworks that are typically presented by consultants. To identify the most 
suitable framework, we already presented a comparison of those frameworks in pre- 
vious work [12] that compares criteria like the purpose, advantages or context of those 
frameworks. With an initial selection of a suitable framework, it can then be extended 
or adapted to the specific needs, leading to an individual approach. 

When designing a scaling approach, practitioners might want to check for coverage 
of the suggested categories of practices (cf. Tables 1, 2 and 3). The practices from 
those categories might be important to consider since the authors of those scaling 
frameworks considered them. The Subway Map provides an overview over the existing 
Scaling Agile Frameworks, and shows the corresponding scaling practices. It can be 
seen that some frameworks are rather similar, sharing many practices, while others are 
rather individual and provide many practices that are not covered in other frameworks. 
We recommend considering the most commonly used practices (cf. Table 4) first, in 
order to implement the best practices of multiple frameworks. In addition, the indi- 
vidual practices can be evaluated to complement the base framework. Our comparison 
of frameworks shows that many frameworks are based on Scrum on team level. 
Practitioners that want to scale up their agile development should first consider their 
implementation of team level practices that support scaled agile development. 


Fig. 1. Subway map visualizing practices of Scaling Agile Frameworks 
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The categorization of scaling practices and the Subway map need to be validated by 
the respective framework experts. Due to lack of documentation, there is the risk that 
wrong categorizations were made or practices from frameworks are missing. Since we 
did not conduct a systematic literature review, it might be that some frameworks or 
some of their practices are missing. For the sake of simplicity of the categorization, 
sometimes practices were clustered without considering the detailed differences. The 
stations of the Subway map have different abstraction levels, since some stations are 
based on practices, others on categories. 


5 Conclusion 


Due to the need to adapt Agile beyond the context Agile methods were initially 
designed for, many frameworks to scale agile have been developed in recent years. In 
order to understand similarities between the frameworks, we extracted a list of their 
underlying practices. A visualization provides a high-level overview over Scaling Agile 
Frameworks and enables comparison of the frameworks concerning the use of their 
underlying practices. Additionally, practices common to many frameworks are iden- 
tified. We discuss how the results help practitioners to build their individual scaling 
framework. Feedback from framework authors is needed before proceeding with an in- 
depth analysis and comparison of the similarities and differences of the considered 
frameworks. 
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Abstract. Modern large software-intensive development organizations are 
nowadays more and more often believed to transform their structures and 
operations towards large-scale agility in search for higher performances. Based 
on a survey conducted in Finland in 2018, in this paper we explore the current 
state of the affairs with respect to how extensively organizations are actually 
transforming themselves, in what ways this takes place in practice and for what 
goals. Most of the respondents were in large organizations. The results show that 
the majority of the surveyed respondents indicated that their organizations have 
conducted agile transformations or are currently doing so. Different strategies 
and tactics have been used in the transformations, but markedly the respondents 
reported most that the company has had external consultants (subcontracting) to 
assist in the change. The most important goals aimed to be achieved with agile 
means were productivity and quality (operative) and responsiveness to 
customer/market changes (new features). Notably only very few respondents 
reported their organizations to be currently non-agile (do not use at all agile 
methods in software development). 


Keywords: Agile transformation - Enterprise agile - Scaled agile - 
Large-scale agile software development - Survey 


1 Introduction and Background 


Agile methods and practices are nowadays mainstream in software development 
organizations. In large organizations agile software development is scaled in size to 
multiple teams and project program levels (large-scale agile). However, agile practices 
and ways of working are also increasingly applied in other functional areas and oper- 
ations of large companies. Moreover, modern software-intensive companies facing 
digitalization are gearing to become agile enterprises — nimble and flexible with business 
agility [1]. These companies may be performing enterprise agile transformations. 
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When agile software development methods and practices are extended and scaled 
up to enterprise levels in large organizations, new competences and organizational 
capabilities beyond software engineering are required to conduct successful agile 
transformations [1, 2]. These include such as organization design and dynamics, pro- 
duction economics and product/service solution management which are all distinct 
disciplines of their own. Each organization should know their needs and goals of agility 
[3, 4]. 

Agile research tends to be lagging behind industrial practice. Assuming that large 
companies are in reality performing agile transformations, there is a need for more 
empirical research. Relevant research topics include how to conduct large-scale agile 
transformations, what the important context factors are, and what the role of the 
established agile scaling frameworks (e.g., SAFe) is [5]. Our research problem is to 
understand why and how different companies want to change with agile means 
including whether companies have conducted agile transformations and to what extent, 
and how beneficial and successful their particular changes have been. Digitalization is 
one of our key context factors. In this paper we present current results with respect to 
agile transformations in large organizations based on our recent survey study done in 
Finland. We have reported related results about agile scaling frameworks (SAFe) 
elsewhere [6]. Notably here we see scaled agile in software development as a means for 
enterprise-level agility in larger organizations. 

Various Agile surveys have been conducted earlier, but nowadays especially the 
fast progress of digitalization makes it topical for different organizations. Agile is 
expanding from pure software industry to traditional, non-software industries and 
scaling in enterprises. Considering prior and related survey works, one of the most 
internationally known ones is the annual State of Agile survey by Version One [7]. In 
Finland a particular scientific survey was done in 2012 [8]. In addition, the annual 
Finnish Software Industry Survey has addressed agility-related points [9]. Our guiding 
motivations for this survey research were to investigate the current state of the agile 
development in Finland taking into account enterprise-level agility and also non-ICT 
companies. 


2 Survey Research Design 


The overall purpose of our survey research was to examine the current state of Agile 
and enterprise agility in Finland. To begin with, we were interested in measuring how 
widely agile methods and practices are currently applied in industrial practice and how 
that is evolving. 

Following this line of thinking we defined a broad range of topics and issues 
ranging from basic ones of agile software methods and practices to company-wide 
matters. Moreover, we aimed to investigate not only the current whereabouts but also 
the future intentions of the companies. The target population was intentionally not 
limited to software companies since we were also interested in non-software companies 
currently facing digitalization and becoming more software-intensive (i.e., companies 
in other industries than IT). 
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The survey questionnaire was composed by starting from our selected main 
research themes and interests stated above. The questionnaire structure comprised the 
following primary sections: 


1. Company’s state of agile 
2. Agile company transformation 
3. Agile future of the company 


The specific questions were compiled on the one hand by referring to prior surveys 
for comparison purposes (e.g., [7, 8]) and by deriving from our industrial experiences 
and our prior works (e.g., [3]) on the other hand. The draft questionnaire was first 
piloted both in our industrial and academic organizations. The final version consisted of 
total of 50 questions (including background information items). Certain questions were 
only applicable depending on their preceding selector questions (e.g., whether SAFe is 
in use or not). The survey was available in both Finnish and in English (translated by 
the first author). 

For data collection the survey was implemented as a web-based online question- 
naire with the Finnish/English language choice. The questionnaire was distributed 
through social media and a proprietary industrial mailing list mass postings to over 600 
people, and it was open for responding for four weeks during November and December 
2018. 


3 Results 


In this paper we present the subset of the full survey result data directly related to the 
research topic of large agile transformations. In the survey the following questions 
addressed specifically that area: 


e When has there been executed or planned agile transformation in Your company 
most recently?! 
— The question was instructed as follows: “Extensive (covering the entire software 
development) change to adopt agile methods, practices and ways of working” 
e How is Your company/has Your company been executing agile transformation? 
Why does Your company want to become more agile? 
Is Your company conducting or planning an agile transformation? 
— This question was applicable for non-agile company respondents only (i.e., the 
ones who reported their company not to use agile methods at all). 


Next, we present the results data of the above main questions. A total of over 400 
replies were received, but only 28% of the respondents finished the questionnaire. Not 
all replied to all questions. In this paper, we report only on the data of those respon- 
dents (119) who replied to the last question in the questionnaire sequence (background 


' In this paper we show the English translations of the Finnish questions regardless of which language 
the respondents have used. 
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information of the respondent). In our web-tool implementation of the questionnaire we 
did not restrict the finishing with mandatory questions. 

The key respondent demographic information is presented in Tables | and 2. 
Notably most of the respondents (74%) were from large or very large organizations. 


Table 1. What is the size of Your organization? 


(multi choice not allowed) n (N = 119, ‘No answer’ choice % (out of 
N/A = 4) N) 

Very large (more than 5000 45 38 

persons) 

Large (more than 250 persons) 43 36 

Middle-sized (50-250 persons 12 10 

Small (10-50 persons) 12 10 

Micro (less than 10 persons) 3 3 


Table 2. What is the primary sector (line of business) of Your company? 


(top 3) (multi choice not allowed) n (N = 117, N/A = 2)| % 
C1 ICT sector (including consulting), information technology 39 33 
C2 Financial sector (banking, insurance) 27 23 
C4 Telecom services 13 11 


Table 3 shows that approximately 40% of the responses indicated that the 
respondents’ organizations have already conducted agile transformations (‘Done’) 
while 30% stated that they are currently (at the time of the survey in 2018) doing that 
(‘In progress’). Furthermore, it tabulates the distributions according to the top industry 
sectors (see Table 2). 


Table 3. When has there been executed or planned agile transformation in Your company most 
recently? 


(multi choice allowed) n (N = 117, % (out C1 C2 C4 
N/A = 6) of N) N=34 |(N=27) |(N=13) 
Done over 5 years ago 15 13 11 0 1 
Done 2-5 years ago 22 19 9 3 6 
Done some one year ago 14 12 1 3 2 
In progress 35 30 5 16 5 
Planned, implementation 8 7 2 3 0 
schedule open 
Under planning (e.g., 5 4 0 4 0 
pilots) 
Not done/planned agile 20 17 8 1 0 
transformation 
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Table 4 gives insights about how the respondents perceived their organizations’ 
transformations conducted in practice. The organizations have applied both bottom-up 
and top-down approaches to their transformations. The respondents indicated the uti- 


lization of external consulting support most (43%). 


Table 4. How is Your company/has Your company been executing agile transformation? 


(multi choice allowed) n (N = 84, % (out of 
N/A = 2) N) 

The company has a strategy for adopting agile ways of 24 29 

working and practices 

The company has initiated the change top-down in the 26 31 

organization 

The company has initiated the change bottom-up (from 34 40 

teams) in the organization 

There is a dedicated agile support team in the company 37 44 

The company has had external consultants (subcontracting) to | 51 61 

assist in the change 

Self-made transformation in the company 13 15 

In other ways (how) 5 6 


We did not ask directly why companies conduct their agile transformations. 
However, insights to that can be inferred from what goals they target to achieve with 
agility. Table 5 summarizes what the respondents ranked the five most important 


reasons for becoming agile for their organizations. 


Table 5. Why does Your company want to become more agile? 


(top 5, multi choice allowed) n (N = 85, % (out 
N/A = 2) of N) 

Productivity and quality (operative) 62 73 
Responsiveness to customer/market changes (new features) 56 66 
Job satisfaction 46 54 
Fast/continuous organizational learning in rapidly changing 43 51 
operating environments 

Competitive and desirable products (new product 41 48 


development) 


Finally, in contrast we were also interested in non-agile organizations (i.e., who 
respond to the question: ‘How widely does Your company use agile methods in 
software development? — We do not use at all’). Only 6 out of the 119 respondents 
were in non-agile organizations. Most of them (5) stated that their organization are not 
active to transform, either (“Is Your company conducting or planning an agile trans- 


formation? — Not in progress/planning’). 
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4 Discussion 


Our key discovery in this study is that agile transformations have been conducted in 
this Finnish sample of organizations already several years ago (see Table 3). They are 
also ongoing in different industry sectors. 

Another key insight is that different large organizations appear to be using different 
strategies and tactics for their agile transformations (see Table 4). There is emphasis to 
have external consultants (subcontracting) to assist in the change. That could indicate 
that the companies have realized to need new competencies and/or additional resources 
to perform their transformations in sustainable ways. Unsurprisingly company internal 
efficiencies were scored the highest goals to be attained with agile means but also the 
external, customer-related goals of agility are important. Such performance effects 
require systematic company-wide capabilities that agile transformations may bring. 

In comparison to the related studies, Rodriguez et al. investigated agile and lean 
adoption (usage of agile and lean methods) in software developing organizations [8]. 
They do not address agile transformation in the large organizational scale like we do. 
With respect to our results (‘The company has initiated the change top-down in the 
organization’ in Table 4) one particular comparable point in their study was that top 
management commitment was the most significant challenge in agile and lean adop- 
tion. Like in our results (Table 5), productivity was the most important goal. Notably, 
though, in our survey questionnaire agile and lean were not combined. 

VersionOne also reports agile adoption (usage of agile practices) rather than 
transformation [7]. However, their 2018 survey concludes that “agile is expanding 
within the enterprise” for instance with product roadmapping. One comparable result 
point in their study is that 30% of the respondents’ organizations have been practicing 
agile development methods for more than 5 years while in our case some 13% of the 
respondents reported their organizations to have performed agile transformation in that 
time frame (‘Done over 5 years ago’ in Table 3). In contrast to our results (Table 5) 
and the study by Rodriguez et al. [8], the most important goal for agile adoption was 
reported to be accelerated delivery speed while productivity was ranked third. 

With respect to non-agile organizations VersionOne reports that 97% of respon- 
dents’ organizations practice agile development methods [7]. In our survey the com- 
parative value is 94%. Strikingly, Rodriguez et al. reported 42% of organizational units 
with no agile nor lean methods usage [8]. This could be due to the differences in the 
sample population or that the organizations have progressed since that time (2012). 

Considering the comparability and generalization, we acknowledge that a validity 
concern in our results is whether all the respondents have interpreted and conceived the 
term agile transformation in the same way (‘Extensive (covering the entire software 
development) change to adopt agile methods, practices and ways of working’). How- 
ever, also Rodriguez et al. did not limit the usage of agile with specific definitions [8]. 

A general limitation due to our survey design is that we did not ask the respondents 
to identify their organization. Consequently, we cannot tell the number of different 
responding companies. Rodriguez et al. acknowledged the same in this kind of survey 
research [8]. Due to the confidentiality reasons we refrain from evaluating how 
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representative our respondent sample is with respect to all Finnish industries. However, 
the respondents represented several different business domains (see Table 2). 


5 Conclusions 


Based on a recent survey conducted in Finland in 2018, in this paper we have explored 
the current state of Agile with respect to how extensively organizations are actually 
transforming themselves and in what ways in practice. Most of the surveyed respon- 
dents perceived to be in organizations which have already conducted agile transfor- 
mations or are currently doing so. Different organizations have used different strategies 
and tactics but external consultant support is often utilized. 

Further work will be done to analyze the survey results more broadly and deeply 
with cross-tabulations covering more questions than was possible in here. Digitaliza- 
tion may affect companies in different business domains and industries differently. 

Our future research plans include repeating the survey study in certain other 
countries and also annually in Finland. That would make it possible to do more 
extensive comparative and longitudinal analysis. 

Furthermore, our questionnaire can be refined and improved based on the experi- 
ences of this first survey round. Considering large agile transformations, a refinement 
could be to enquire whether the transformation covers the company fully (enterprise 
agility) or partially — and how exactly (only software development/IT or certain 
functions/levels) [10, 11]. Additional context factors to support the results analysis 
could be what particular business environment variables, regulations, certifications or 
other such requirements and constraints influence the software development of the 
company. Naturally, already the business domains (Table 2) inform such factors in 
general. 
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Abstract. The benefits of agile ways of working in small teams have inspired 
larger organizations to implement large-scale agile frameworks. To manage 
dependencies between teams, there is a need for routines to plan and divide 
work between teams as well as routines to manage emerging dependency issues. 
These routines are often changed over time, but how tailoring is performed is 
not much studied. This study aims to fill that gap by presenting the tailoring of a 
planned coordination routine in three organizations over a period of one and a 
half year. By visiting planning sessions, 379 h of observation data were col- 
lected. Investigating details of this routine gives a much more dynamic view, 
compared to the static description presented in the framework. Different logics 
for tailoring could be seen in the three cases. For deciding on a cadence for the 
planning period, three diverse logics were used as the basis for the decisions: 
knowledge, time, and resources. 


Keywords: Inter-team coordination - Large-scale - 
Agile software development - Scaled agile framework - Routine dynamics 


1 Introduction 


There is an industry trend towards adopting agile methodologies in-the-large, and 
although research into agile software development (ASD) has matured in the past years, 
agile in large-scale settings are not much explored [1]. Although some studies are 
reported from large-scale transformations, such as the presented studies in Dikert, 
Paasivaara, and Lassenius [2], there are few studies investigating implementations of 
large-scale agile frameworks. This study can help to bridge that gap. 

A suggested future research agenda for large-scale ASD was a call for further 
research in how coordination change over time [3]. Coordination can either be planned, 
such as dividing work in advance and identifying dependencies or designed to deal 
with emerging dependency issues, such as daily or weekly meetings to solve problems 
[4]. Different ways to coordinate are sometimes called practices [5], mechanisms [5, 7], 
or routines [4]. Feldman and Pentland define organizational routines (hereafter, simply 
routines) as “repetitive, recognizable patterns of interdependent actions, carried out by 
multiple actors” [7, p. 94] which well describes different ways of coordination and 
therefore the term routine will be used henceforth. 

For example, Dietrich et al. [5] studied the different types of coordination routines 
on individual versus group mode used in large-scale ASD, and Dingsøyr et al. [6] 
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studied different types of coordination routines used in a large-scale ASD program and 
how they evolved. Both studies present a list of routines for coordination in large-scale 
agile settings but do not investigate in detail how the routines were changed or tailored 
in detail from a performative aspect. This paper focuses on the details of one specific 
planned coordination routine performed in large-scale ASD with the research question: 
How is the PI planning routine tailored in SAFe implementations? 

To answer the research questions, three case organizations were investigated: Auto, 
a product development department within the Automotive industry. Gov, a project at a 
Government Agency in Sweden, and Bank, a development department in one of the 
four largest business banks in Sweden. The observations at these case organizations 
started when they implemented the Scaled Agile Framework (SAFe), and observations 
went on for one and a half year. 


2 The PI Planning Coordination Routines in SAFe 


SAFe consists of a number of roles, artifacts, and routines, and this is a brief 
description of one investigated routine for planned inter-team coordination. PI plan- 
ning, as described in SAFe [7], is a routine for dividing work and identifying depen- 
dencies between teams for a set period of time into the future. SAFe explains that “PIs 
are typically 8—12 weeks long. The most common pattern for a PI is four development 
Iterations, followed by one Innovation and Planning (IP) Iteration” [7]. According to 
SAFe, the typical iteration is hence two weeks long. 

The importance of PI planning is explained on the website: “PI planning is essential 
to SAFe: If you are not doing it, you are not doing SAFe” [7]. The routine follows a 
strict two-day agenda (see Fig. 1) where the first half day comprises different pre- 
sentations followed by “Team Breakouts” where each team plans their work. 

The first day ends with a presentation and review of a draft plan and the first half of 
the second day is used for adjustments and further planning and ends with a presen- 
tation and review of the final plan. The second, and last, part of the second day 
comprises risk management, a confidence vote (in which teams vote on their confi- 
dence in meeting their planned PI objectives) and a joint retrospective for all teams and 
stakeholders participating in the PI planning workshop. Depending on the result of the 
final plan review and confidence vote, an undefined amount of time [8] is set aside for 
rework of the plan to be finalized before the end of the second day. Out of the two full 
days, only five hours (30%) is dedicated for team breakout time. 

Something that is not visualized in the standard agenda is to conduct a number of 
inter-team meetings called Scrum of Scrums (SoS) during the team breakout sessions 
where all Scrum Masters attend to follow up if teams are following the intended 
planning schedule. A number of questions are raised in these meetings such as “Has 
capacity (velocity) been identified for each iteration?”, “Have any program risks been 
identified?”, and “Have dependencies with other teams been identified and/or 
resolved?” [9]. These meetings are also called SoS Sync to differ them from the 
ordinary SoS meetings which are conducted during the program increment, often two 
or three times a week, to sort out emerging team dependency issues [8]. 
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GRUE Management Review 
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Fig. 1. PI planning standard agenda. (source: Scaled Agile Framework [8]). 


As can be seen, the way to conduct PI planning is expressed in a prescribed manner 
regarding the steps to be performed. Conboy and Carroll [10] put forth, in a study of 13 
agile transformations, that the risk of implementing a common framework is that it 
imposes too many restrictions and rigidity on the employees. On the other hand, the 
lack of guidelines from a common framework may lead to a lack of common direction 
in the agile implementation as Paasivaara et al. [11] pointed out from studying the 
company Ericsson. 


3 Method 


Observations, using field notes and photographs, together with memoranda from 
meetings, were used as data for the study. On-site visits and observations in the various 
cases are presented in Table 1. Results are presented in a tabular format as well as a 
short narrative describing the identified results. The analysis is comprised of investi- 
gating and comparing differences between the detailed prescribed way of conducting PI 
planning according to SAFe and how the PI planning routine was performed in the 
three cases. The studied organizations (Auto, Gov, and Bank), had a history of agile 
ways of working between four to six years before starting to implement SAFe. The 
cases were chosen because they all had experience and maturity in agile ways of 
working, since the study focuses on the implementation of a large-scale framework, not 
implementing ASD per se. Also, it was essential to select cases which were at the 
beginning of implementing the SAFe framework, to be able to follow tailoring from the 
very starting point. The teams at Bank and Gov were each organized as one unit, also 
called an Agile Release Train (ART) [8]. At Auto, they were divided into three ARTs, 
hence the many hours spent on observation in this organization compared to the other 
two cases. 
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Table 1. The number of on-site visits and hours of observation. 


Case | # of on-site visits | Hours of observation 
Auto | 6 196 
Gov 5 113 
Bank | 6 70 
Total | 17 379 


The on-site observations were conducted during a number of PI planning work- 
shops, from April 2017 until November 2018, a period of one and a half years, as 
depicted in Fig. 2. 


Bank: PI O Bank: PI 1 Bank: PI 2 Bank: PI 3 Bank: PI 4 Bank: PI 5 


Feb | 
oF a a” o 


Apr May Aug Nov Dec May Jun | 
5 â zm FT Say Sy A SS 


Apr 


| Auto: PI 3 ad PI4 Auto:|PI 5 Auto: PI Auto: PI 7 Auto: PI 10 
Gov: PIO Gov: PI 1 Gov: PI 2 Gov: PI 3 Gov: PI 4 


Fig. 2. On-site observations at the case organizations. 
Data was collected from the starting point of the implementation of SAFe at Bank 


and Gov while Auto had started their transformation three months prior to the first 
observation and had already conducted two PI planning workshops. 


4 Results 


The results presented in Table 2 are from the first and the last observed PI planning 
workshop. 


Table 2. Data from PI planning at Auto, Gov, and Bank from the first and last observation. 


Case Auto |Gov Bank | Auto | Gov Bank 
PI 3 PI 1 PIO |PI10 |PI4 PI 5 
Number of weeks per PI 10 12 6 10 15 11 
Number of iterations per PI 3 4 2 3 5 4 
Iteration length (weeks) 3 3 2:5 3 3 2,5 
Length of final IP iteration 1 week | 2,5 days | None | 1 week | 2,5 days | 2,5 days 
PI planning workshop (hours) | 12 15 10 11,5 12 12 
Number of SoS syncs 3 2 2 2 0 5 
Number of SoS sync questions | 8 7 13 8 0 5 
Team breakout time (hours) 5,5 4,5 4,9 7,5 8 7,5 
Team breakout time (percent) | 45,8% | 30% 49% | 65,2% |66,7% | 62,5% 
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Auto was conducting their third PI planning during the first observation, and all 
three ARTs had decided on a set 10-week cadence, all three within the same week. The 
cadence remained the same all through the observation period but the agenda changed 
over time, mainly by removing common presentations and adding time for team 
breakout sessions. Amount of time for team breakout changed from 45,8% of time used 
for PI planning up till 65,2% in the last observed session. 

PI 0 at Gov was not a real PI planning but a one-day information workshop to incur 
buy-in of SAFe to the five teams and let them meet physically since two teams had their 
home office in another city. A follow-up from the first real PI planning, PI 1, showed 
lots of negative feedback where draft plan reviews and risk resolving meetings were 
mainly seen as waste and “unhelpful status meetings”. Gov did not use time as a basis 
for cadence but instead the amount of resources, in this case, available man-hours. For 
the summer months, PI:s were longer since many employees go on vacation. 

Negative comments were also put forth regarding the SoS sync meetings at Gov. 
Gov started out with two SoS sync meetings during their first PI planning, where scrum 
masters answered seven questions twice during the two-day workshop. In their second 
PI planning, they only held one SoS sync meeting, and in the third PI planning, they 
abandoned the SoS sync entirely. Auto started out with three SoS syncs but later 
reduced this to two SoS syncs per PI planning, still keeping the same format with eight 
follow-up questions. Bank, on the other hand, started with two longer SoS syncs, 
answering as much as thirteen follow-up questions but changed the format to become 
shorter (only five questions to answer) and more often (five times per PI planning). 

At Bank, the first PI was only aimed at planning two sprints and not, as prescribed 
by SAFe, intended to become a set cadence. Instead, Bank proposed shorter PIs during 
the first PI planning sessions in order to train team members and to get shorter feedback 
loops on tailoring the PI planning routine. During the last observation, PI 5, four sprints 
had been used as PI length for two times, and Bank did not see any benefits in reaching 
for more extended planning periods. Instead, four sprints became the fixed cadence for 
future PI planning workshops. 


5 Discussion 


The planned coordination routine called PI planning is described in SAFe as a two-day 
workshop with a prescribed standardized two-day agenda where teams in an ART plan 
according to a fixed cadence “typically 8-12 weeks long” where the “most common 
pattern for a PI is four development Iterations, followed by one Innovation and 
Planning (IP) Iteration” [8]. But is this a proper PI format and is the proposed standard 
schedule a suitable format for PI planning? Since the second most reported obstacle 
reported in Laanti and Kettunen [12] was that SAFe was not fitted correctly to the 
organization, tailoring is probably needed. But how could the planning routine be 
tailored? Three organizations with disparate business logics were investigated to 
answer the research question: How is the PI planning routine tailored in SAFe 
implementations ? 

Investigating details of this specific planned coordination routine in the three case 
organizations gives a much more dynamic view, compared to the static description 
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presented in SAFe [8]. The planning periods observed ranged from 6 to 15 weeks and 
at Bank, deciding on a set cadence from the start was not the intention. Instead, the 
logic at Bank was during the beginning of implementation to have shorter feedback 
loops to be able to tailor PI planning according to the needs of the ART. At Gov, the 
cadence was based on amount of resources available, meaning that PI:s during spring 
or fall were shorter than in the summertime since more employees go on vacation in the 
summertime. Deciding on a cadence for a PI can, as can be seen in the three cases, be 
based on different logics. In the Bank case, the length of the planning period was 
decided based on having short early feedback loops to learn how to conduct PI 
planning quickly. At Gov, the same amount of available resources was the basis for the 
length of the PI while Auto used what SAFe prescribes: the same number of weeks per 
PI. Also, although SAFe claim two weeks to be the typical length of iterations, this was 
not true in any of the cases as they all preferred longer iteration times: 2,5 versus 3 
weeks in length. 

In all three organizations, feedback from the teams was that too much time was 
spent in joint meetings which were mainly seen as waste. Time was instead added for 
teams to plan, the so-called Team Breakout sessions. At Gov, the first PI planning 
workshop was conducted according to SAFe prescription with 30% of the time spent in 
Team Breakout, the least amount of Team Breakout time compared to Auto and Bank. 
At the last observed PI planning workshop at Gov, teams spent 66,7% of their time in 
Team Breakouts. The increased amount of time spent in Team Breakout was also seen 
at Auto and Bank. This suggests that organizations implementing SAFe values Team 
Breakout more than other suggested items in the PI planning schedule. 

Although the time-span of the PI during the last PI planning was within suggestions 
from SAFe (8—12 weeks) at two of the organizations and one even longer (15 weeks at 
Gov), none of the organizations felt the need for more than one and a half day to plan. 
This suggests that the suggested amount of time to plan is perceived as unnecessary 
long. 

Planned PIs consisted of three to five sprints, and Auto was the only case which had 
an actual IP iteration at the end of the PI (which lasted for one week). Both Gov and 
Bank only allowed one day for innovation and the rest of the time (1,5 days) for 
planning the next PI. This is somewhat surprising since a basic idea of SAFe is to have 
time set aside for improvement and innovation [8]. An area for future research is to 
investigate why such little time is allowed for improvement and innovation in some 
organizations and the implications of these different approaches. Are organizations who 
allow more time for innovation more innovative or does not the allowed time for 
improvement have the intended effects? 
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Abstract. Large-scale agile projects bring inter-teams interaction challenges. 
Teams need to be autonomous, but often crosscutting concerns affect many 
teams. If the teams fail to collaborate on these concerns, the negative effects 
might hinder agility in the medium and long term. In other words, the organi- 
zation and the system accumulate debt, on which the teams pay a high interest. 
Such debt must therefore be prioritized and “repaid” timely. We conducted a 
case study with interviews, observations and document analysis. Via both team- 
and large-scale retrospectives we investigated how teams coordinate and discuss 
Technical-, Social- and Process Debts. 


Keywords: Large-scale software development - Coordination practices - 
Communication - Technical debt - Process debt - Social debt - Retrospective 


1 Introduction 


Large software companies strive to become more responsive in identifying and satis- 
fying their customers’ needs. One strategy for increasing responsiveness is the intro- 
duction of autonomous teams and agile software development [14]. However, when 
many agile teams are working towards the same goal in a Large-Scale Agile 
(LSA) project, a lot of coordination and management effort is required [13]. If each of 
the autonomous team in LSA setting works independently, team development pro- 
cesses and technical solutions would ultimately differ and may be highly disconnected 
from one another. Further, a high level of team autonomy and a need for constant 
delivering value to the customer, can lead to sub-optimal processes that might have 
short-term benefits, but generates a negative impact for the organization in the medium- 
long term. Examples of negative impact can be duplicated work, misunderstandings 
and integration problems. 

In recent literature, a financial metaphor has been successfully used to describe such 
phenomena: aiming for short-term goals is equivalent to taking a debt, and the addi- 
tional negative impact paid in the medium-long term is considered the interest that is 
paid on such debt. Although the metaphor has been used to describe prevalently 
technical issues (hence the term Technical Debt [4]), the debt metaphor has been used 
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to describe other kinds of sub-optimal solutions, for example related to the social 
structure of the development community (Social Debt [16]) or to the development 
processes (Process Debt [1, 8]). However, how different types of Debt are identified 
and managed in LSA, is still an open question. 

As an example, let us take what is called Architectural Debt: in LSA, system cross- 
cutting concerns (e.g. maintainability, usability and performance) and the consequent 
technical solutions, need to be envisioned at a higher level than from a single team 
perspective. As an example, if the concerns are not well separated in the system (which 
represents the Architectural Debt), several teams might find themselves working on the 
same shared component. Changing the same component in parallel, hinders the teams; 
they have to coordinate, merge conflicts and share the responsibility of the component. 
This, in the end, either creates a lot of overhead for the teams or causes the component 
quality to degrade, making future changes problematic (these effects are the interest 
paid on the debt). Communication is key to avoid these problems and might not happen 
if not supported by practices shared across the teams. 

Recent literature in LSA has provided a better understanding on how teams 
coordinate; Dingsgyr et al. [5] describe 14 mechanisms for inter-team coordination in 
large-scale software projects. They found that coordination of work between teams 
influences teams’ internal processes and how each team makes decisions. Nyrud and 
Stray [11] identified 11 coordination mechanisms in a large-scale agile project and 
found retrospective meetings to be important for continuous improvement of the inter- 
team coordination mechanisms. Further, managers need to be sensitive to the coordi- 
nation needs as they change over time in large programs [10]. 

However, to the best of our knowledge, there are no related studies addressing the 
challenge of balancing the management of technical-, social- and Process Debt in LSA. 
We aimed to understand which types of debt that require inter-team coordination in 
LSA by answering the following research question: 

RQ: What types of debt are elicited and discussed on team level and inter-team 
level in a large-scale agile project? 


2 Technical-, Social- and Process Debt 


Different types of debts have been researched. However, Technical Debt (TD) is the 
one for which the most literature is available. The definition of TD is [2]: 


“[...]a collection of design or implementation constructs that are expedient in the short term, 
but set up a technical context that can make future changes more costly or impossible. [...]”’. 


Different types of TD have been identified. The most common ones are [8]: 


e Code Debt, which is related to sub-optimal code solutions. For example, not 
declaring a variable that later requires manually changing all the instances in the 
code. 

e Architectural Debt is regarded as sub-optimal solutions with respect to an ideal 
architecture. For example, a monolithic architecture with many dependencies across 
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modules requires teams to change the code in many places for any change. This 
might require more time to deliver features and might introduce bugs. 

e Test Debt is regarded as lack or sub-optimal tests. For example, low code coverage 
or the lack of structured and automated tests can be considered test debts. 

e Documentation Debt is the lack or sub-optimal documentation. An example could 
be the lack of description on how APIs work, which hinders developers when 
correctly accessing modules, components or services across the system. 

e Infrastructure Debt is related to sub-optimal solutions in the development envi- 
ronment. For example, buggy knowledge management tools. 


Other types of debt (non-technical) have also been identified in literature as causing 
negative impact, namely Social Debt and Process Debt. 

As for Social Debt, it is referred to as “the presence of sub-optimality in the 
development community, which causes a negative effect” [16]. An example of Social 
Debt is the lack of proper communication among key parts of the organizations (e.g. 
between development and operations). Another example is having an architecture team 
that is disconnected from the team and therefore might suggest architectural solutions 
that are not realistic, as they do not take into consideration details and requirements 
elicited during implementation. 

On the other hand, Process Debt is mentioned as a type of debt that needs to be 
managed [1, 8], but there exists no current definition for it. We therefore use our own 
operational definition based on the ones reported for the other types of debt. We define 
Process Debt as “a sub-optimal activity or process that might have short-term benefits, 
but generates a negative impact in the medium-long term”. An example of Process 
Debt might be that teams conduct stand-up meetings where the focus is reporting status 
so that the leader knows what is going on [15]. The short-term benefit is that the team 
members satisfy their leader’s need for knowing project status. However, a long-term 
negative impact is that the meeting centers around reporting and not about sharing 
knowledge and solving dependencies which is more valuable in the medium-long term. 
Another example is a large-scale project having the presence of many meetings to 
coordinate, which might seem important for solving dependencies, but disrupts the 
development work compromising the project efficiency [3, 15]. 


3 Research Methodology 


Since the goal of this research was to explore and provide insight into the phenomenon 
of both technical and non-Technical Debt in LSA, we designed a case study [18] to 
observe the various types of debt in practice. We chose a large-scale project that 
develops a new platform supporting public transportation as our case. The project has 
thirteen development teams ranging between five and fourteen team members working 
towards the same products. 

Understanding the design or implementation constructs that are expedient in the 
short term, but that can make future changes more costly or impossible is a complex 
problem. There is a need to understand challenges and improvement suggestions 
together with what is working well. Further, there is a need to get many stakeholders of 
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the LSA project together as no one in an LSA project has the full overview of the 
situation. Also, the teams need to discuss issues that (potentially) negatively impact one 
or more teams and involve more than one team (inter-teams) such as shared 
components. 

Conducting retrospective meetings is an important and popular practice in agile 
software development [17], and applied both on team-level and in large-scale agile [6]. 
The meetings are utilized for improving the way of working, and participants often 
discuss past challenges and how to overcome them to work better together in the future 
[7]. Therefore, we chose retrospectives as the primary source of our data collection for 
studying our research question. We chose to study team-level retrospectives (see 
Fig. 1) and a large-scale retrospective. Additionally, we conducted two informal group 
interviews to prepare for the retrospective sessions. All the six reports from the 
meetings were imported into NVivo. We analyzed the meetings by categorizing the 
reported issues into the different type of debts described in the background section. 


Fig. 1. Issues discussed during one of the team retrospectives using DAKI 


e Team Retrospectives: In November 2017 we facilitated a retrospective meeting in 
Team Alpha (see Fig. 1). This retrospective meeting had eight team members 
present. We also collected four reports from their previous retrospective meetings. 
These reports included what had been reported as positive and negative issues in 
addition to action items (often with a person responsible for following up the item). 
These retrospectives had been held between December 2016 and September 2017. 

e Large-Scale Retrospective: We facilitated a retrospective meeting with project 
leaders, product owners and the team leaders in the LSA project; 13 people in total. 
The focus in this retrospective was on a large delivery they had been working on 
from May to November 2", 2017. To elicit the relevant problems we chose to use 
an exercise where participants discuss issues that need to be dropped, added, kept or 
improved (DAKI) [12]. This exercise uses four quadrants where participants can 
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place issues and is good to use when there is a high number of participants and 
issues. We then facilitated a discussion of the most urgent items by using the 
technique Lean Coffee [9] (Table 1). 


Table 1. Data collection 


Data Explanation Number 
Informal group Questions about the teams, how they were working, the 2 
interviews roles and their retrospective meetings 

Retrospective We collected reports from Team Alpha 4 
reports We facilitated a retrospective in Team Alpha 1 
Retrospective We facilitated a retrospective meeting with representatives |1 
meeting in one team | from teams in the LSA project 

Large-scale 

retrospective 

4 Results 


We observed which different types of debt were discussed in team retrospectives 
compared to a large-scale retrospective. This would tell us if some types of debts seem 
to be more team issues (and would not require coordination) rather than inter-team 
issues. 

We therefore report such comparison by counting the number of issues for each 
type of debt in Table 2. First, we outline the difference between Process, Social Debt 
and overall Technical Debt. Then, we show the number of issues related to the sub- 
types of Technical Debt. We omit Code Debt, as we did not find any Code Debt issue 
discussed. 


Table 2. Number of issues discussed in team and large-scale retrospectives 


Debt type Team retrospectives | Large-scale retrospectives 
Process debt 24 17 
Social debt 37 15 
Technical debt 26 11 
Architecture debt 6 2 
Documentation debt} 7 2 
Infrastructure debt 7 2 
Test debt 6 5 


We report, in Table 3, the issues that were discussed in both team retrospectives 
and LS retrospectives, as well as some of the issues that were instead discussed only on 
a team level. This would show the difference between which issues were autonomously 
addressed and which ones required coordination. Below the table, we list the only two 
issues that were brought up during the large-scale session only (related to Test Debt). 
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Table 3. Issues that were discussed by teams only and issues that were re-proposed for inter- 
team discussion and coordination 


Debt type Re-proposed at inter-team level Team retrospectives only 
Architecture e Unstable APIs (teams e Deployment issues 
debt modifying often) 


e Unclear module responsibilities 
(more structure needed) 


Documentation e Need for spread the e Documentation issues for specific 
debt documentation across teams modules 
Infrastructure e Problems related to Jira and its | Ħ Issues related to a specific 
debt usage for stories and epics knowledge management tool used 
by the team 
Test debt* e More automated tests e Test coverage 
e More test follow-up e Specific test structure 
Process debt e Have more demo sessions e Issues related to a specific team 
e More and better structured process (e.g. team planning) 
planning 


e More meetings preparation and 
effectiveness (too many 
people) 

e Specific release event not well 
executed 

e More pair-programming 

e Agile definition (e.g. sprint 


definition) 
Social debt e Team autonomy e Slack usage and content 
e Involvement and e Team specific roles (e.g. specific 
synchronization with module testing responsibility) 
leadership e Team specific competences (e.g. UX, 
e Sync with POs, PMs, etc design) 


¢ Information and knowledge 
across teams 

e Common goals 

e Communication and 
involvement of UX developers 


*Test Debt issues that were discussed on Large-Scale Retrospectives only: 
¢ Better definition for acceptance criteria for tests 
e Better end-to-end tests 


5 Discussion and Limitations 


The aim of this work was to understand which types of debt that require inter-team 
coordination in LSA by answering the following research question: What types of debt 
are elicited and discussed on team level and inter-team level in a large-scale agile 
project? 
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5.1 What Types of Debt Are Elicited and Discussed on Team Level 
and Inter-Team Level in a Large-Scale Agile Project? 


This study provides an initial source of evidence on the concepts of Technical-, Social 
and Process Debt, and that inter-team coordination is required to tackle the various 
types of debt. First, we found that many of the Process Debt issues were re-proposed in 
the inter-team discussions, which implies that Process Debt needs coordination to be 
solved, potentially even more than other types of debt. Second, teams discuss heavily 
Social Debt issues in team retrospectives, and part of the issues are discussed again in 
large agile retrospectives, especially related to team autonomy, leadership and com- 
munication across teams. Third, Technical Debt is discussed in team retrospectives, but 
only part of it is re-proposed for inter-team discussion. 

We did not find Code Debt discussed in retrospectives at all. As for Architecture, 
Documentation, and Infrastructure, inter-team coordination seems to be necessary 
when it comes to APIs, documentation used across the teams and the usage of the tools 
that are used by more teams. 

We found a special case related to Test Debt, as some issues were re-proposed 
(automation, structure), while others were discussed only on a team level. In addition, 
some of the Test Debt-related issues (e.g. related to acceptance criteria, end-to-end 
tests) were discussed only on an inter-team level: it seems that such issues were elicited 
thanks to the joint discussion among teams. 


5.2 Limitations and Future Work 


In this paper, we used retrospectives to answer our research question. However, other 
sources of data, for example from other forms of communication, should be analyzed to 
complement the findings. For example, it could be that architectural issues are dis- 
cussed in meetings that are more technical rather than in retrospectives. Furthermore, 
more cases should be analyzed to understand if the results are similar in other large- 
scale agile projects or if the studied project was a special case. 
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Abstract. Agile practices are popular within software development. But when 
applied to large projects with many teams, coordination challenges arise. The 
projects working title “Coordination in large-scale agile software development: 
An investigation of coordination mechanisms, communication, roles, autonomy 
and interdependencies” summarizes the main topics of investigation. While all 
theoretical and analytical approaches to the data material is not yet determined, I 
have already started fieldwork in one company which will serve as a main 
longitudinal case, with more to follow as the project proceeds. Initial fieldwork 
has revealed that there are differences in how agile teams coordinate their work 
across teams. I will continue to explore these differences. End goals of the 
project include to identify success criteria for coordination in large-scale agile 
software development projects. 


Keywords: Large-scale agile - Software development - Coordination 


1 Introduction 


The main objective of this PhD project is to contribute to successful software devel- 
opment projects in the digital age, through contributing to a better understanding of 
coordination in large-scale agile software development projects. There is a recognized 
need for more research on how to adjust agile practices to large-scale contexts [1—4]. In 
particular, there is a need for more knowledge on coordination in autonomous agile 
teams in large-scale settings [3, 5, 6]. Here, I have the opportunity to study large-scale 
agile projects in a Scandinavian context, where companies seek inspiration from 
companies like Spotify and Ericsson. 

This paper is organized as follows: Sect. 2 outlines some of the relevant back- 
ground and related work on large-scale agile software development as well as some 
theoretical approaches to coordination. In Sects. 3 and 4 I present my preliminary 
research objectives and research design, while Sect. 5 outlines the next planned steps 
for the research project. 
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2 Background and Relevant Work 


2.1 Large-Scale Agile Software Development 


Agile teams are autonomous and cross-functional in nature, where team members are 
assumed to make their own decisions and utilize their competence across different 
organizational functions and roles. This is thought to contribute to a flatter organiza- 
tional structure with increased empowerment and participation, assumed to contribute 
to more efficient decision-making [6-9]. 

Despite that agile methods originally were intended for smaller team projects [10], 
and primarily has been successful in small teams [3], the practice of using agile 
principles and techniques has spread to include large-scale projects and organizations 
as a whole [9, 11]. At the same time, the research community on agile software 
development called out the need for a unified framework for understanding large-scale 
agile software development [12]. As a response to this, a taxonomy of scale for agile 
software projects was developed, where small-scale agile software development 
includes one team only, large-scale from 2—9 teams, and very large-scale from 10 teams 
and up [12]. 

When scaling up agile, several challenges arise, such as coordination between 
teams, stakeholder management and keeping to the agile principles [1, 3, 5]. One 
challenge with applying agile to large-scale is that there is a lack of a common, agreed 
upon understanding of agile working methods [13]. Rather, agile can be understood as 
a set of values, principles and practices, that may be implemented in more or less 
successful ways. As such, there may be great differences in how large-scale agile is 
implemented [14], and finding consistent results from large-scale agile may be difficult 
[13]. Initial fieldwork supports these observations. In Berntzen et al. [15] we discuss 
how differences in Product Owner coordination may be related to that teams in the 
large-scale case program under study may freely choose among agile methods, in other 
words, they do not work consistently with one agile approach. 

Another challenge is related to how large-scale frameworks, such as the Spotify 
model, Large-Scale Scrum and the Scaled Agile Framework may affect large-scale 
coordination. Such frameworks are gaining in popularity, but there is still a need for 
more academic research on such practices, as there is little research supporting that 
agile principles can be directly applied to all organizational processes without adjust- 
ment or tailoring [1, 14, 16]. 

Among the many challenges inherent in the successful implementation of large- 
scale agile coordination appears to be a key issue. Dikert et al. [1] identify inter-team 
coordination as one of the major challenges in need of more research. Coordination, 
often defined as the managing of interdependencies [17] is recognized as important 
across literatures on software engineering, information systems, organization and 
management [26], and theories on coordination has been developed [4, 17]. While 
researchers have started exploring coordination in large-scale agile [1—3, 5, 16, 18, 19], 
there are still many open questions in need for further investigations. 
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2.2 Coordination Theories 


Coordination Theory 

Malone and Crowston [17] developed an interdisciplinary, broad-based theory of 
coordination, known today as Coordination Theory (CT). In their seminal paper, 
Malone and Crowston [17, p. 4] defined coordination as a process of “managing 
dependencies between activities”. CT is based on ideas from organization theory, 
management, economics and computer science [4]. The basic tenet of CT is that 
complex organizational systems are made up of dependencies (such as shared 
resources, task interdependencies, simultaneity constraints and relationships with cli- 
ents, each with different sub-dependencies), which constrain situational action, and thus 
must be coordinated. Coordination then, is made up by various coordination processes 
and mechanisms which each address one or more dependencies in a situation [17]. 
What these processes and mechanisms are and how they work vary with the context. In 
the context of large-scale agile software development, they can include for instance 
scheduled and unscheduled meetings, artefacts and physical settings [4, 20]. These 
mechanisms may facilitate action constrained by the dependencies, however, the in the 
large-scale setting, perhaps the mechanisms themselves may also both enable and 
constrain coordinated action? 

CT has contributed with a much-cited definition of coordination, a modelling 
framework for analyzing coordination in complex processes and providing a beginning 
of a typology of dependencies and coordination mechanisms [21]. However, it does not 
provide any propositions or testable hypotheses [17, 21]. In a ten-year retrospective of 
CT research, future research to develop testable hypotheses from CT is encouraged, for 
instance about the generality of coordination mechanisms and more structured 
approaches to evaluate alternate coordination processes [21]. 

Despite the limitations of the theory in terms of lack of causal explanations and 
testable hypotheses, CT has proved a useful theoretical framework for the study of 
coordination. In the IS field, CT has been used in particular in software engineering and 
systems design, where researchers have noted the importance of coordination chal- 
lenges and the potential for computer systems to help groups and teams collaborate 
better [21]. In the context of agile software development, CT has been applied by 
Strode and colleagues [4], who used the theory as basis for their own development of a 
theory of coordination in agile development. 


The Theory of Coordination in Agile Development 

To take advance theory and research on coordination in agile SD further, Strode and 
colleagues [4] build on Coordination theory but extended with a theoretical model and 
a total of eight testable propositions. In particular, this theory proposes that effective 
coordination in agile settings are comprised of coordination strategies contributing to 
coordination effectiveness. Coordination strategies are defined as a group of coordi- 
nation mechanisms that manage dependencies in a situation. They consist of three 
components; synchronization, structure and boundary spanning activities and artefacts 
that contribute to overall coordination effectiveness [4]. 
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Coordination effectiveness, in turn, consists of explicit and implicit effectiveness. 
Explicit coordination effectiveness emphasizes the physical objects (both persons and 
artefacts) involved in the project. For explicit coordination effectiveness to occur, the 
required object needs to be in the right place, at the right time and in the right state so 
that is “ready for use” as perceived by each individual involved in the project [4, 17]. 
Having the right tools in place to conduct a video meeting or having available 
developers to take on new tasks as they flow from a different team can be examples of 
this type of explicit coordination effectiveness. Implicit coordination effectiveness on 
the other hand, relates to coordination that occurs within work groups without explicit 
passing of messages. The authors further posit that implicit coordination consists of five 
components; “knowing why”, “knowing what is going on and when’, “knowing what 
to do and when”, “knowing who is doing what” and “knowing who knows what”. In 
other words, implicit coordination requires a high degree of shared goals and under- 
standing both of one’s own and others knowledge [4]. In relation to agile development, 
where the team is central [22], implicit coordination in terms of shared knowledge 
indeed appears important to overall project effectiveness. 

Importantly, in this theory, these are considered outcomes resulting from the 
coordination strategy. The theoretical model proposes that there is a causal relationship 
between an agile coordination strategy and project coordination effectiveness; if the 
strategies are well implemented, coordination is more effective. This in turn, is pro- 
posed to contribute to the agile software development project success [4]. In addition, 
they propose that project complexity, uncertainty and organization structure may affect 
the coordination strategies, but they did not test this while developing the theory. 

Despite its clear relevant to the study of coordination in agile development, this 
theory is difficult to readily apply it my PhD project because it considers intra-team 
coordination and does not consider the multiple team aspect and inter-team coordi- 
nation, which may introduce important constraints to effective coordination. In order to 
apply their theoretical model to large-scale agile development, it could be necessary to 
expand the model to include elements such as for instance team size, number of teams, 
number of functional elements involved in the project as well as differences in team 
autonomy in their usage of agile methods and choice of technologies across teams. 
Accordingly, one route may be to further develop the theory to account for scale. 
Another route is to look further into theories that may take into account the multiple 
team aspect, and the various differences these entail, through focusing on the coordi- 
nation process itself through a relational lens. 


Relational Coordination Theory 

Relational Coordination Theory (RCT) [23] represents a third theoretical perspective on 
coordination. RCT originates in the organization studies field from research conducted 
in the airline industry in the 1990s [23], where Gittell observed substantial difference 
between companies in the extent to which the employees shared collective goals and 
knowledge towards the overall work process and outcome. Today, RCT is an estab- 
lished and empirically validated theory, and has been studied in various (non-agile) 
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large-scale settings, most notably in the airplane, health and education industries [24]'. 
RCT has recently been picked up by Information Systems researchers [25-27], how- 
ever, it appears it has not yet been applied in large-scale agile development. 
Relational coordination is defined as “a mutually reinforcing process of interaction 
between communication and relationships carried out for the purpose of task integra- 
tion” [28]. These relationships can be between individuals, roles or even departments 
and organizations. According to RCT, relationships provide the necessary bandwidth 
for coordinating work in settings with that are highly interdependent, uncertain and 
time-constrained. Effective coordination in these settings is carried out through rela- 
tionships of shared goals, shared knowledge and mutual respect. These, in turn, are 
theorized to be mutually reinforced by high-quality communication (that is, frequent, 
timely, accurate and problem-solving communication). It is interesting to note that 
these assumptions bears resemblance to Strode et al.’s implicit coordination effec- 
tiveness [4] described in the above section. The resulting positive relational context 
enables a well-coordinated process with less wasted effort [23]. Finally, an assumption 
of RCT is that relational coordination has is stronger in more horizontally designed 
organizational structures [29]. Because large-scale agile software development pro- 
cesses are also typically characterized by high levels of interdependence, uncertainty 
and time pressure, in combination with other coordination theories, I believe RCT is an 
interesting lens for studying coordination in large-scale agile development. 


Further Theoretical Considerations 

Although the above presented theories all can contribute to the understanding of 
coordination processes in large-scale agile, it is still necessary to focus not only on the 
social and human aspects of coordination, but also the role of the product under 
development and the technologies being used during the development. 

All three coordination theories offer some concepts that address coordination in 
large-scale agile development, however the role of large-scale itself, as well as the 
potential implications of both the technology being used for coordination, and the 
technology being developed is perhaps not fully addressed. In order to fully accom- 
modate these theories to be relevant for large-scale agile development, and to make 
valuable theoretical contributions to IS and SE fields, it may be relevant to draw on 
other theories and concepts. As one overarching project goal is to address how coor- 
dination mechanisms are used in and across teams, and as initial fieldwork has indi- 
cated that teams in large-scale agile projects coordinate differently [15], it is important 
to address how different coordination mechanisms may be used in different ways. To 
this end, I believe that other theories and concepts from the IS field, such as 
sociotechnical systems perspectives, affordance theory [30] and/or the concept of 
boundary objects [31] could help me understand how teams go about using agile 
practices and tools differently, depending on their needs and goals, and how this in 
turn, may reinforce differences through the different action possibilities offered by e.g. 
technological communication tools, meetings and physical artefacts used in agile 
activities [32]. 


' A full overview of research results from this line of research is beyond the scope of this paper. See 
for instance [24], an overview of research and future directions of RCT. 
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Getting the theory right is a substantial task in a PhD project, and a task I will direct 
much attention to in the time to come. However, as I will continue to explore how RCT 
may inform my research project, I will explore recent literature combining RCT with 
approaches taking into account the role of the technology itself. For instance, Clagett 
and Karahanna [26] explore the role of relational coordination in digitally mediated 
work processes and focus in particular on distributed information exchanges for 
dependency management and the role of boundary spanners in facilitating digitally 
mediated coordination. Bozan [25] applied RCT in an empirical investigation of col- 
laboration and creative group problem solving in a virtual, distributed team environ- 
ment and found that RCT’s elements of high-quality relationships and high-quality 
communication did have a positive impact on creative problem-solving in distributed 
teams. 

In the further development of my PhD project, I will look into these and other 
theoretical approaches to identify the best suited approach to understanding coordi- 
nation in large-scale settings. 


3 Research Objectives and Preliminary Research Questions 


The main objective of the project includes identifying success criteria for coordination, 
such as how to handle interdependencies, enable good communication and better 
autonomous team-work processes in large-scale agile software development projects. 
The final output will be a dissertation in the form of an article collection with con- 
ference and journal papers. 

To gain more understanding about the topics outlined above, I will explore in a 
field setting research questions such as: 


e How are coordination mechanisms used in and across large-scale agile software 
development projects? 

e How do Product Owners coordinate work in large-scale agile software development 
[15]? 

e Which interdependencies operates in and across teams in agile software develop- 
ment projects and what challenges do they pose for team efficiency? 

e What is the role of written communication in large-scale agile coordination? 


Some of these research questions may be too broad in their current form. Therefore, 
they will be reworked as the empirical studies are conducted. 


4 Research Design 


To address the research questions, I primarily plan to use qualitative research methods 
in a longitudinal case study. The case study approach was chosen because case studies 
provide depth and detailed knowledge [33] and there is little research-based knowledge 
about how POs coordinate work in large-scale agile. Data will be collected in the field 
from several companies associated with the Autonomous teams-project (A-teams) in 
collaboration with SINTEF. 
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The data collection methods will include participant observation, individual and 
potentially group interviews, document analysis [34] and surveys [35]. Collecting a 
rich data material that can be analyzed in different ways to gain a broad understanding 
of the research topic and to address the outlined research questions. 


4.1 Case Description 


I have conducted field work in a large-scale agile development program, referred to as 
the PubTrans program, since September 2018. The data so far has been collected from 
a large-scale case in which almost the whole development program is co-located and 
working with agile development methods. The program started in 2016 and aims to 
develop a new platform supporting public transportation. 

The PubTrans program has thirteen development teams ranging between five and 
fourteen team members working toward developing the same products. Each team is 
responsible for their part of the overall product. The PubTrans program can thus be 
classified as very large-scale agile [12, 36]. In order to coordinate work within and 
across teams, the program makes use of various electronic tools, such as Slack, Jira, 
and Confluence; material artefacts such as task boards; and various scheduled and 
unscheduled meetings. The development teams may choose freely how they solve their 
tasks and may rely on agile methods of choice. As such, there is no one unified agile 
approach across the teams. 

I spend 1-2 days a week there, observing how they work and attend in particular 
inter-team meetings. In addition, twelve interviews were conducted in October 2018, 
with a focus on the Product Owner role, and one interview with a team leader was 
conducted April 2019. More interviews, with more roles, are planned the coming fall. 
In addition, I have access to a wide range of written documentation, including Slack 
logs, Confluence pages and company wiki. 

Based on the data collected so far, one conference paper has been presented and 
published [15]. This paper explores through an RCT lens how Product Owners coor- 
dinate within and across agile software development teams in a large-scale public 
sector program in Norway. Data collection in this program will continue throughout the 
PhD research project, with supplemental data collection in other companies to follow at 
a later stage. 

In addition to my own presence at the PubTrans program site, one of my super- 
visors are taking an active part in the fieldwork conducted there. In collaboration, we 
make sure to provide the program with regular feedback and keep them well informed 
about the research progress. Whenever a paper is written and sent for review, they are 
given opportunity to review and approve the data used and results presented, and are 
offered opportunities to contribute also in terms of co-authoring. Nurturing a good 
relationship with the case organization is seen as highly valuable for both parties. 

All in all, the PubTrans program proves an increasingly valuable case to work with. 
My access to data is good, and the processes and changes we observe them doing 
proves interesting and worthwhile of continuous focus. Initially, I planned to include at 
least three company cases, devoting approximately the same amount of time and efforts 
to each of them. However, over the past months I have decided that the PubTrans 
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program should serve as the main case for a longitudinal, in-depth case study which 
can provide rich empirical insights into the research topic [33]. 

Despite the advantages of longitudinal case studies, there is an inherent trade-off in 
terms of potential lack of generalizability to other companies and settings [33, 37]. 
Here, researchers need to weigh the benefits and disadvantages against each other in 
making a decision. As one means to improve generalizability to other settings, towards 
the end of the data collection, I will collect supplemental data from other companies I 
have access to. This data collection will not be as detailed as that of the PubTrans 
program, however it may serve to cross-check some of the observations and findings 
into other settings to see if there are great similarities or differences from the PubTrans 
program to other settings. Of course, no two organizations are alike, so differences are 
likely to observed. Nevertheless, it is thought worthwhile to do such additional data 
collection to strengthen my findings. 


4.2 Validity Issues and How to Address Them 


In terms of validity, which threats and how to control them depends on the research 
method. For qualitative methods, researcher bias is important to address. I intend to rely 
on data triangulation, using both interviews, observation and document analysis. Tri- 
angulation generate more substantial data, addressing the topics under study from 
different angels [33]. Further, the analysis of the qualitative data material will involve 
textual coding. I will use programs such as Nvivo 12 for organizing the codes and 
conducting the analyses, however, bias and validity threats are prevalent when coding 
data. Own preconceptions on behalf of the researcher and fatigue are only two of these 
threats. Further, as much of the analyses will be conducted at least partly in collabo- 
ration with others, I will make sure to assess the inter-rater reliability for the analyses to 
try to assure coding reliability and validity. My supervisors have strong expertise in 
qualitative research methods, and they will help me ensure validity is sufficiently 
addressed. 


5 Current Research Status and Next Planned Steps 


This research project is still in an early phase, and despite the encouraging outset, much 
remains to be done. In this section, I will describe some of the outstanding issues that 
should be clarified as I proceed with the research project. 

First, the literature on agile software development is already substantial, and the 
literature on large-scale agile is growing. As I continue to go through these bodies of 
literatures, I will conduct a literature review to gain a fuller overview of the current 
state of research on coordination in large-scale agile software development. Here, 
examining both research papers and the practitioner literature may be a worthwhile 
endeavor, as there is a substantial practitioner literature within this field. 

Second, I will work further on the scope of my research, as it is still somewhat too 
broad. This includes further delineating the theoretical approaches as well as narrowing 
down the focus of my research questions. While I will continue exploring the usability 
of RCT as a theoretical lens for understanding coordination in large-scale agile, I will 
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need to pin down how theory can inform my understanding of how technologies used 
during development, as well as the product under development, affects coordination. 

Finally, I am already planning to collect enough data to allow me to carry on with 
my research also after the completion of the PhD research project. As described above 
in Sect. 4, I plan to collect survey data that can be analyzed quantitatively. Much 
research in the SE field and on large-scale agile is qualitative, which makes it inter- 
esting to see whether quantitative research can bring new insights. I have an interest in 
both types of research. Before starting my PhD, I have also conducted quantitative 
research based on surveys from another research project. These studies explore dis- 
tributed, autonomous teams in relation to their coordination under conditions of dif- 
ferent levels of initiated and received task interdependence [38] and in relation to how 
distributed team members perceive certain leadership styles [39]. Continuing such lines 
of research in a large-scale agile setting could be an interesting future research project. 

However, as it can be argued that qualitative studies are more suitable when 
exploring new grounds [33], I will conduct qualitative research for the PhD project and 
potentially supplement with quantitative studies at a later stage in my career. In con- 
clusion, doing research on coordination in large-scale agile software development is an 
exciting endeavor. Many challenges lie ahead as this PhD project continues; however, I 
remain optimistic about the future and look forward to tackling these challenges as they 
unfold. 
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Abstract. In reaction to reports of recent high-profile software security and 
privacy failures in our always-on agile world, users and regulators are 
demanding that companies deliver more trustworthy and resilient systems. This 
panel discussed some of the strategies and best practices for “building-in 
security” to our products and systems in contrast to “bolting-on security” — and 
how threats should be assessed and mitigated to avoid the unintended conse- 
quences of flawed design decisions. 


Keywords: Security - Privacy > Design 


1 Security and Privacy at XP 2019 


Security and privacy issues for today’s computer systems and applications are in the 
headlines. Every day there are business stories about companies who lose customer data 
to hackers, stories about system outages caused by hackers, and stories about shadowy 
networks of criminals who take over computers and blackmail helpless companies, 
governments, and ordinary users. The panel discussion on security and privacy issues 
was motivated by the special challenges to building software systems in an agile way: 
even in a lightweight development process, all developers still need to pay attention to 
software quality, security from hackers, and protection of the private data of users. 

The panel represented a cross section of industry experience in software applications. 
Landon Noll is a computer security expert, astronomer, and frequent traveler to the South 
Pole. He currently works for Cisco in California. Kelsey van Haaster is a software 
engineering expert at ThoughtWorks Australia who works on her company’s internal 
security practices: passwords, security hygiene, and identity-related issues. Scott Ambler 
is a consultant, coach, and author of books on object-oriented design and Agile devel- 
opment methods, and he is currently Senior Consulting Partner at Scott Ambler + 
Associates based in Canada. Dennis Mancl worked as an internal software engineering 
and software quality expert at AT&T and Lucent in New Jersey. Robert Crawhall is a 
Principal Consultant at Innoxec in Ottawa, Ontario, where he developed technologies for 
government and industry, including nuclear power and telecom systems. Steven Fraser, 
the panel impresario, is based in California where he advises on tech transfer and open 
innovation strategies for Innoxec. Previously he was the Director of the Cisco Research 
Center and the Lead for HP’s Global University Programs — and he has organized and 
delivered over 75 software engineering conferences, panels, and workshops. 
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2 Security and Privacy Panel Discussion 


Agile development creates special challenges in developing software systems that 
appropriately address security and privacy. 

In this panel, the following issues were raised by the panelists: Security design 
should cover prevention, mitigation, and detection of security issues. Good “security 
hygiene” is an important practice for all software designers and developers. Many of 
our devices today are inherently insecure, and we need to be aware of the risks as we 
design our systems. In any development effort, especially in a fast-paced Agile 
development cycle, it is important to identify the security requirements up front and 
always include these requirements in the test planning and execution. Today’s devel- 
opers need to address more government regulations on security and privacy. In an 
Agile environment, customers need to be made aware of security tradeoffs. In addition, 
there is a significant “training gap” in security and privacy training. 

Landon Noll started the discussion by asserting that we can never be perfect at 
preventing security and privacy issues in our software. We should try to prevent 
security problems when we can, but whatever we can’t prevent we should try to 
mitigate, and whatever we can’t mitigate we should at least try to detect. 

Landon explained that testing, logging, and monitoring are the most important 
security-related practices and tools for development teams. Development teams need to 
think about security tests up front, and the teams need to have a process to continuously 
improve tests as the team learns more. An Agile development approach is valuable 
because it supports continuous improvement. Landon explained the value of Agile’s 
focus on improvement, “I think Agile process gives you a really good way to be in this 
continuous process of improving your testing, testing your improvements, measuring 
your improvements, measuring the logging, and logging the measurement.” 

But there is no silver bullet for security and privacy. Landon warned about some of 
the risks of our current security technology. Many of our security technologies are 
inadequate. Landon pointed out, for example, “We demand too much from hash 
functions — more than they can deliver.” He complained that many of our security 
standards say “use this cryptographic hash function,” but the best hash functions “are 
being attacked faster than Moore’s Law.” Cryptographic hash functions are at the heart 
of authentication and communications security systems, including digital signatures 
and public key cryptography [1]. Landon concluded that designers of most secure 
systems don’t pay enough attention to important activities in using encryption tools, 
such as key generation and key management. 

Kelsey van Haaster emphasized the importance of good security hygiene. In her 
company, security is everyone’s concern. “At ThoughtWorks, we ensure that every 
consultant (whether they are a software developer or a business analyst or a project 
manager) goes through our App Sec 101 training. When we are working with clients 
and building products, both for clients and internally, we take the approach that the 
security stories need to be there from iteration zero. We build that into part of our 
process right from the start.” 

Scott Ambler and Landon Noll told some cautionary tales about the theft of 
information from our computers and devices. 
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Scott had security and privacy anecdotes from his days working for IBM where 
some global customers of IBM would routinely try to steal data from visiting outsiders. 
His colleagues in the IBM sales organization knew which companies were “bad 
actors,” and they would warn him, “Don’t bring your phone and laptop to this customer 
site.” They suspected that even an encrypted hard drive could be vulnerable. 

Landon reported about the deficiencies of today’s hardware: “The overall state of 
computer hardware is somewhere between appallingly poor and unacceptably poor.” 
Every computer is vulnerable if a hacker finds a way to load and execute small selected 
chunks of code. According to Landon, “All commercially available microprocessors 
today are subject to having their integrity compromised by a sequence of non- 
privileged instructions.” This is bad news for digital security for applications such as 
containers, virtual machines, IoT, and cloud computing. 

Dennis Mancl advocated for the importance of security requirements — which need 
to be part of the requirements documentation even in Agile development projects. 
“Security requirements are really important, because if you are going to test a system, 
what are you going to test it against? If there are no security requirements, they don’t 
care about it.” 

The ITU-T X.805 security architecture recommendations include a set of eight 
security dimensions, and every system needs to have some security requirements in 
each area [2]. The security dimensions are linked to potential security risks, threats, and 
vulnerabilities. Access control and authentication requirements specify the rules for 
physical and network access to a system and the rules for application and network 
passwords. Non-repudiation requirements explain the transaction records and logs that 
must be maintained to allow stakeholders to prove that an event took place. Data 
confidentiality and communications security requirements ensure that data is kept 
private. Data integrity requirements describe the internal system processes to prevent 
data from unauthorized duplication or modification. Availability requirements define 
the responses to system overload and to denial of service attacks. Privacy requirements 
prevent disclosure of information about users’ network communications activities, such 
as the IP address of a user or websites the user has visited. 

Security requirements are not easy to write. When writing security requirements, it 
helps to consult with experienced testers. Testers can give constructive suggestions for 
key security requirements to include in requirements documents or user stories, based 
on the testers’ experiences with security testing for similar systems. 

Security analysis often needs to focus on “negative” behavior. Many security 
requirements are “misuse cases” — key scenarios that explain what things need to be 
prevented or mitigated. In Agile development, too many of the user stories written by 
developers and users are unrealistically positive: most of them are “the system acts nice” 
stories. It is a good idea to get together with friends who are testers when doing user 
story brainstorming, because testers are better trained to think about negative cases. 

There are many new security and privacy regulations in place, such as the European 
Union’s General Data Protection Regulation (GDPR), which was put into effect in 
2018. Robert Crawhall explained the pressures on governments to create new security 
regulations. 

Robert agreed that governments really want commercial computer systems to be 
more secure and private, but “government has a very limited toolbox.” Their standards 
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are intended to improve focus on certain issues by companies. “When the government 
gets to control the supply chain, they start implementing standards to try and cover their 
butts.” This explains complex standards like the GDPR privacy rules. It is impossible 
for governments to catch every violation of the new security or privacy regulations, but 
they can make an example of a few big companies who don’t follow the rules. “If 
you’re the European Union, you bring in GPDR for the same reason — and you hope 
that handing out a few $5 billion fines will cause industry to sit up and take notice.” 

Some of the audience members added their own observations. “Today, I got an 
email request from where I work — telling me to log in using my credentials to do 
security training on how not to click bait in email.” Landon was interested: “Did you do 
the training?” “No, of course not.” 

The same audience member had another complaint about the effect of GDPR on 
application interfaces. Users are asked to agree to allow access in the middle of an 
application, and this access permission process is extremely superficial. “I would 
suggest that GDPR makes us significantly less secure and private than we have ever 
been. Because to access anything, no matter what it is, you have to say ‘Yes, I agree’. 
So all of a sudden, we are giving permission on purpose to access data, and we are not 
reading all of the levels of permission we are giving.” 

One question from the audience explained the problems of getting customers to be 
interested in security. “Often your customer — when you do work for a large company 
and they have a Product Owner for an Agile project — they want their features. So they 
find it hard to prioritize security.” Even if the customer understands the need for some 
good security hygiene and some up-front analysis of security issues, it can be easy for 
them to put a lower priority on adding new security functionality to face new threats. 
Some customers are just hard to convince that they should invest in security prevention 
and attack analysis. 

Kelsey explained how at ThoughtWorks, the teams actively include businesspeople 
in the project inception process — the early discussions where security scenarios and 
other iteration zero tasks are planned. She explained, “They don’t need to get involved 
in the technical details, but there is always a financial or a business or a reputational 
risk that those folks care about.” 

Robert commented that a company needs strong accountability and transparency in 
its decision-making process. Early in his career, he worked on the design of nuclear 
power plants, and the “signoff” process ensured that engineers took quality seriously. 
“In a 40-year engineering career, the one day I still remember is when I put my stamp 
on the design of a nuclear pressure vessel, with implications for northern Ontario if I 
made a mistake on the calculations.” 

Strong oversight can also help. Robert explained that in his experience in the 
development of nuclear power plants, the ultimate yes/no decisions on all quality-related 
issues were signed off by the “head of quality” for the company, who reported directly to 
the CEO. If a decision went wrong, it was clear who was responsible. 

Scott and Robert reported on aspects of customer apathy and ignorance. Scott 
pointed out the inevitability of customer apathy: “The problem is you’re fighting 
human nature. It’s human nature not to think about bad things.” He talked about how 
many people build houses in river floodplains or in coastal areas vulnerable to hurri- 
canes. And Robert pointed out the differences between the layout of the original 
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Canadian telephone trunk network and the design of the internet exchange network a 
generation later. The main east-west trunks of the older telephone networks went 45 
miles north of Toronto: “if they lost Toronto, they didn’t want to lose the telephone 
connection between Montreal and Calgary.” But in the 1990s, Bell Canada chose to 
install their main Toronto internet exchange in downtown Toronto in the One Front St. 
building, at street level, subject to flooding and perhaps vulnerable to a terrorist attack. 
Robert comment was “it’s because it became deregulated.” 

One questioner lamented the lack of education in digital security issues and sug- 
gested that security training needs to start in elementary schools. “At what point should 
we teach software developers how code is compromised based on data, and proven 
practices to avoid those compromises?... in all of my time and all of my education 
since I started teaching at the undergraduate level in 1971, I have never seen a course 
teach this.” If no one learns about digital security issues, developers will continue to 
build systems with weak security. 

Robert and Landon suggested that teaching about digital security ought to be done 
when middle schoolers or elementary school students first learn about programming. 

Robert explained that as part of the Cyber New Brunswick initiative, the schools in 
the Canadian province of New Brunswick now all include cyber security concepts in 
the middle school curriculum. Robert explains, “They need to catch kids before they 
make the STEM/not-STEM decision.” 

Landon explained that it is important for young people to learn to think about what 
can go wrong. He offered his experience in teaching security thinking at kids camps: “I 
get them to do something simple like print ‘Hi mom.’ Then I ask ‘How can you mess it 
up?’ One clever girl, she thought a little bit, then she went over and turned off the 
computer.” Once you have figured out how to mess something up, “you need to think 
about how to fix that messing up,” and then go back and forth with the students. “They 
learn that they maybe need to save their work.” It starts them thinking about how to 
analyze problems. 

Scott explained that the education and training gap about security is part of a bigger 
problem. “When are we going to start teaching people to code/program? Forget asking 
when we’re going to teach programmers how to be secure, when are we going to ask 
our people to have adequate educations? I work in banks and insurance companies, and 
most of the developers in the IT space don’t have a background in programming. They 
don’t have the fundamental skills of their jobs.” 

Scott explained that we would be making the same comments in a panel on User 
Experience or Performance, because there are similar gaps in knowledge and experi- 
ence across industry in those areas. 

Kelsey pointed out that companies can play a role by putting computer security 
resources in the hands every employee and their families. “We provide every employee 
with a family subscription for a password manager, and we insist that they in fact use 
it.” Kelsey points out that this can save money: “it is cheaper than something going 
horribly wrong.” This is a policy that can have a positive long-term impact: “Kids of 
our employees are growing up understanding about their own personal security.” 
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3 Summary 


Security and privacy will continue to be important issues to address for Agile devel- 
opment. The panelists all warned about the gap between security threats and the current 
security technologies. They pointed out the deficiencies in software development 
training — not enough focus on what can go wrong. In a corporate environment, 
security is everyone’s concern and all developers and users need to practice good 
security hygiene. It is essential to document the security requirements in the course of 
developing a system. Some security and privacy standards, such as the GDPR privacy 
rules, may actually create new security and privacy risks. There can be a disconnect 
between the development teams and the Product Owner about the relative value of 
work items that improve an application’s security infrastructure. Finally, everyone 
needs some encouragement and training in security and privacy issues: something as 
simple as a company-provided family subscription for a password manager can 
improve the awareness of good security practices. 

Landon summarized the main message about security and privacy for the audience: 
“Train early. Test often.” He concluded with a message of Agile improvement: An Agile 
process supports “continuously improving your testing, testing your improvements, 
measuring your improvements, measuring the logging, logging the measurement.” 
Small group of developers can “go off and try to see if they can break something, and 
figure out how to mitigate that.” It’s a process that requires new software to be tested 
early: “and continue testing from the foundations, as your code needs to work — and to 
work correctly — with the reliability, privacy, and integrity that you need.” 


References 


1. Chi, L., Zhu, X.: Hashing techniques. ACM Comput. Surv. 50(1), 1-36 (2017). https://doi. 
org/10.1145/3047307 

2. International Telecommunications Union (2003): ITU-T X.805 Security architecture for 
systems providing end-to-end communications. https://www.itu.int/rec/T-REC-X.805- 
200310-I 


Open Access This chapter is licensed under the terms of the Creative Commons Attribution 4.0 
International License (http://creativecommons.org/licenses/by/4.0/), which permits use, sharing, 
adaptation, distribution and reproduction in any medium or format, as long as you give appro- 
priate credit to the original author(s) and the source, provide a link to the Creative Commons 
license and indicate if changes were made. 

The images or other third party material in this chapter are included in the chapter's Creative 
Commons license, unless indicated otherwise in a credit line to the material. If material is not 
included in the chapter's Creative Commons license and your intended use is not permitted by 
statutory regulation or exceeds the permitted use, you will need to obtain permission directly 
from the copyright holder. 


t) 


Check for 
updates 


XP 2019 Panel: Agile Manifesto — Impacts 
on Culture, Education, and Software Practices 


Dennis Mancl!“® and Steven D. Fraser © 


1 MSWX Software Experts, Bridgewater, NJ 08807, USA 
dmancl@acm. org 
2 Innoxec, Santa Clara, CA, USA 
sdfraser@acm. org 


Abstract. Manifestos are often a vehicle to trigger change by catalyzing dis- 
cussion around a core group of ideas and values — and there is no doubt that the 
publication of the “Agile Manifesto” in 2001 increased visibility for an emer- 
gent breed of lightweight software practices. The panel discussed how the Agile 
Manifesto has impacted academic and industry software professionals in the 
areas of culture, education, and software practices. 
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1 The Agile Manifesto at XP 2019 


The Agile Manifesto [1] is the most widely read statement of agile values and prin- 
ciples. At the time it was written (2001), many of the thought leaders in software 
development practices were already beginning to use lightweight Agile development 
methods: Scrum, Extreme Programming, Adaptive Software Development, and others. 
The term Agile was coined to explain the common values behind all of these light- 
weight approaches. Many Agile instructors and coaches talk about the Agile Manifesto 
and its values when they deliver introductory agile training. 

But today, many who come to university software engineering courses or corporate 
training courses in Agile development have never heard of the Agile Manifesto. As 
Agile approaches to business practices are spreading, the Agile Manifesto looks a bit 
out of date and developer centric. For example, the Manifesto’s opening phrase refers 
to “better ways of developing software” and one of its four declarations is that 
“working software” is more important than comprehensive documentation. 

Is it time to revise the Agile Manifesto? How is the Manifesto received by a new 
generation of Agile practitioners, and what kind of impact is the Manifesto likely to 
make on the future of Agile education and Agile culture? 

The panel represented both academic and industry experiences. Rebecca Wirfs- 
Brock is a design methodologist, a consultant on patterns and Agility, and an author of 
two influential books on software design. Rebecca is the founder of Wirfs-Brock 
Associates and is based in Oregon. She also serves as the Director of the Agile 
Experience Reports initiative for the Agile Alliance. Maria Paasivaara is an Associate 
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Professor at IT University of Copenhagen, with experience in running empirical studies 
in the area of software engineering and software development practices. Werner Wild is 
an Agile coach and consultant with Evolution Consulting in Austria, and he has sig- 
nificant teaching experience at technical universities in several European countries. 
Evelyn Tian is a full-stack Agile coach and trainer with Evelyn Konsult AB, based in 
Sweden. She has coached companies and collaborated with universities on different 
continents, and she is an Advisor to IEEE Software Board. Steven Fraser, the panel 
impresario, is based in California where he advises on tech transfer and open inno- 
vation strategies for Innoxec. Previously he was the Director of the Cisco Research 
Center and the Lead for HP’s Global University Programs — and he has organized and 
delivered over 75 software engineering conferences, panels, and workshops. 


2 Agile Manifesto Panel Discussion 


In this panel session, the panelists explored a number of questions about the Agile 
Manifesto’s impact on culture, process, and education in the software development 
community. The main discussion topics: 


e Is it time to update the Agile Manifesto? 

e How has the Manifesto affected the educational practices we use to teach software 
development in universities? 

e How useful are Agile games in education? 

e How do we assign grades to students when they are asked to work on a project as 
part of a team? 


Some people believe in the Agile Manifesto with a religious fervor, and they would 
never want to change it. Other people believe the Agile Manifesto should be “agile,” 
which means it should evolve as needed. And there are some complaints that the Agile 
Manifesto is too old and too limited, maybe as a result of the biases of a group of 17 
specific people in a mindset of 2001 technology — it has been pointed out before that 
the group was all male persons (no women) and mostly consultants. 

The panelists were asked about whether it would be a good idea to update the Agile 
Manifesto to take into account eighteen years of evolution in Agile development 
practices as well as the increased interest in applying Agility to non-software problems 
in business. Rebecca Wirfs-Brock asserted that the Manifesto not likely to change: it is 
“immutable... at this point in time.” Because the Manifesto is owned by the original 
authors, it will never be changed. Maria Paasivaara agreed, citing a 2018 journal paper 
by Philipp Hohl and others that summarized some recent interviews with the original 
Manifesto authors [2]. 

Even if they can’t change the Manifesto, many people who want to be Agile feel 
compelled to extend it. Rebecca mentioned seeing this compulsion in her role working 
with Agile experience reports. She has seen a trend for Agile teams to talk about their 
attempts to “rewrite the Manifesto” to fit different contexts, including projects that 
don’t involve software. She gave an example: “We had someone last year writing about 
how these principles and practices were restated for working in a research laboratory.” 
In almost every case, their changes are minor edits of the Manifesto text, not major 
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reworking of the content or structure. It is clear that they find that the principles and 
values of the original Manifesto are “mostly” true, just software focused. 

The Agile Manifesto became popular in the 2000s because of “good timing,” 
according to Rebecca. It was written at a time when many researchers and industry 
managers saw the software industry swinging in the direction of heavyweight software 
development techniques such as the Rational Unified Process, with formal design 
diagrams and a complex design lifecycle. But there always was an active software 
development process counterculture, and the ideas of lightweight process had been 
explored for many years. It just needed a catalyst to turn into a visible movement. 

Rebecca explained that the authors of the Agile Manifesto found a way to stir 
things up, to rally other people to follow a different path. “Manifestos are like shaking 
your fist in the air, declaring that this is something different. It was trying to pivot the 
pendulum from this stodgy, heavy process.” 

All of the panelists had examples of the impact of Agile on software engineering 
education. The biggest trend in many universities is to have students work on real- 
world problems, where they will get direct experience in the Agile mindset. Many 
educators feel that this is a much better than having their students learn a set of Agile 
practices merely by reading a book or attending a traditional lecture-based course. 

The panel session audience included some faculty members from universities that 
were still following the model of standard lecture courses. These professors were 
curious about how they could improve the educational process for their students. 
Rebecca suggested something simple: “You just announce that you are setting up a 
practicum with project-based work, and then start doing it in an agile way.” A professor 
could recruit some local small businesses to get involved (to propose some small 
software development projects) and some students to do the development work (with 
professors or students acting as Agile coaches). Students will learn a lot from the 
experience of talking with customers and demonstrating their software to real users. 

Werner Wild mentioned his personal experiences with Agile training from his 
many years of teaching at universities in several European countries. Werner explained 
the evolution in teaching: “Teaching changed completely from lecturing to walking 
around. I did a measurement on my last course at TTU in Denmark, we had 70 students 
spread all over a floor like this here, and I walked between 6 and 10 km every day 
between the teams.” Instead of lecture, Werner’s university courses today offer more 
opportunities for students to work together on real software projects. His role has 
changed “from hierarchy to face-to-face teaching” and he acts “as more of a coach 
rather than just presenting the wisdom of previous generations.” 

Maria and Evelyn explained that companies are often pulled into using Agile by 
students, and students are finding that companies are looking for interns and new hires 
with knowledge of Agile. 

Maria explained that some companies got interested in Scrum by working with 
student teams. She recently taught a pilot course where student teams worked on small 
Agile projects with outside companies. One of the companies was not using Agile, but 
one person from the company acted as a Product Owner for the student team. “He liked 
Scrum so much when he saw how the students were working that he decided that they 
will start using Scrum in their company. Now they are starting to learn Scrum just 
because of our student team.” 
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Evelyn told the story about markets pushing students to learn Agile. She collab- 
orated with universities at both undergraduate and master level to teach about Agile, 
Scrum and Product Ownership. “When students were looking for jobs at job fairs, most 
companies were looking for Agile and Scrum. The university started to feel the 
pressure, and university folks started to think that we should teach Agile to their 
students.” Evelyn worked closely with universities to help the situation. The goal was 
to have students equipped with foundation-level knowledge and practices, ready to 
contribute. 

Maria talked about creative education and training approaches in the Agile world. 
One questioner was interested in hearing more about the value of “Agile games, 
workshops, and special learning experiences.” Maria uses Agile games in many of her 
university courses, and she has written several conference papers on the subject [3]. In 
the panel session, Maria recounted her experiences at two universities: “Students really 
like to use the games. They are really engaged. When I have asked their opinion 
afterwards, and they say that in the game sessions, the time just flies.” She uses games 
to teach Scrum (using a Scrum Lego game) and Kanban (Test Kanban game). 

Werner agreed on the value of games in early Agile training: “Games are one of the 
things that drew me into field, because it was always fun. You run into things that 
crazy-looking at first glance, but when you apply it you realize how valuable they are.” 

Games can play an important role in educating corporate executives about the Agile 
mindset. Evelyn Tian explained that after running an Agile game, she would get the 
executives to do an activity to reflect on the Agile Manifesto — to create their own 
Leadership Manifesto by writing four new statements in the form “we value A over B” 
for the context of executive management. When she coaches companies who are 
considering to adopt an Agile scaling framework, she would ask the managers to reflect 
and create a Scaling Manifesto. The managers would therefore consider the factors 
behind the scaling practices, rather than just going with a framework that makes them 
feel safe and then move into pure implementation mode. 

Assigning grades to students for project work is a big challenge. One questioner 
asked: “So much of Agile is about teamwork and collaboration, yet the university 
insists on individual assessment. How can we motivate students to really get involved 
in Agile and really play nice in a team, when we are only really assessing them as 
individuals?” 

Everyone shared some experiences about how they assigned grades for team 
projects. The grading process shouldn’t be limited to assigning grades to each code 
module written. Rebecca noted that the learning process isn’t limited to students 
developing their coding skills: “People pick up skills and contribute in different ways 
on Agile projects. Not everyone is the fastest coder or algorithm designer, but they can 
contribute to the team.” 

One approach to grading is to assign group grades. When Maria was a professor in 
Finland, she was able to assign grades by team: “In Finland, we worked it so that every 
member of a team receives the same grade, unless the team members decide they want 
to give a lower grade to one person who has not contributed that much and then give 
another person a higher grade.” When Maria moved to Denmark, she had to change her 
approach to grading, because educational regulations in Denmark require instructors to 
assign individual grades. When Werner was a professor in Copenhagen, he had each 
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team give final project presentations — and there was a fixed set of project questions 
which they posed to team members in a round-robin sequence. It became very clear 
when there was a team member who hadn’t contributed to the team’s final product. 

The panelists referred to “Agile mindset” throughout the discussion. 

Maria noticed the Agile Manifesto is not a well-known document among the 
current generation of computer science students. Although most of her students already 
knew a little bit about Agile when they came to her class, “what they always seem to 
know is the some of the practices. When I ask them if they know what thoughts 
underlie the practices — what is says in the Manifesto — they have no idea.” She isn’t 
sure how to teach the mindset, but she thinks that the mindset is more important than 
the practices. 

Rebecca and Evelyn both believed that it takes time to teach the Agile mindset, and 
beginners to Agile may need to get some experience with the practices before their 
brains can absorb the concepts of the Agile mindset. Rebecca explained “when you are 
a beginner, you do things without asking why or knowing why.” But she also pointed 
out that some beginners will be curious, and they will ask why. While supporting 
organizations with Agile transformation, Evelyn said she focuses on encouraged 
behaviors that are aligned with Agile values and principles, which reduces uncertainties 
and also builds an environment to experience the values and principles. She explained 
some of the logic behind experiential learning: “Instead of lecture-based training that 
tries to convince people that something is important by telling them so, it is better to 
have them experience the value and get convinced by themselves.” 

Werner related his experiences teaching Agile concepts to people outside of the 
software developer community. He has already been successful teaching Agile to 
management consultants in the Chamber of Commerce in Innsbruck, Austria, and he is 
looking forward delivering an introductory Agile course to 10-year-olds in Innsbruck in 
summer 2019. 


3 Summary 


While the Agile Manifesto will remain unchanged for the foreseeable future, it has 
already succeeded in creating a revolution in software development practices. Certainly 
there will be new ways of doing things in the future, so many people will continue to 
feel the need to write their own version of the Manifesto to apply to their own context. 
The Manifesto will continue to have an impact on culture, education, and software 
practices. The panelists focused on Agile’s impact on both the content and style of 
teaching software development — especially in European universities. In Europe, many 
universities have included Agile development in their curriculum, to meet the demand 
from industrial companies in Europe. One of the biggest challenges in teaching the 
practices and values embodied in the Agile Manifesto is how to teach students the 
Agile mindset. 
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Abstract. Is “Business Agility” the next frontier for Agile? With increased 
visibility, companies are adopting Agility into the diverse functions of their 
organizations — moving beyond engineering and IT — to operations, marketing, 
sales, human resources, and administration. This panel at the XP 2019 confer- 
ence discussed the latest Agile trend and its implications for practitioners and 
businesses worldwide. 
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1 Business Agility at XP 2019 


Business Agility is a new and challenging topic for the Agile community and the XP 
conference. It’s a “new market” for Agility, with more consulting and coaching jobs to 
support business transformations. Although many of the Agile principles are similar, 
Business Agility is very different from Agile development for software products. Agile 
coaches and consultants are learning to understand the problems of organizations 
across the business, and they are discovering how to build seamless interactions 
between the business and IT. 

The panelists shared their views based on their Agile experience and business 
experience. Two panelists are experienced Agile coaches, and two panelists are directly 
involved in program management, which requires working with product development 
teams in engineering or IT as well as other business functions such as sales, finance, 
and human resources. Steve Adolph is an Agile coach working for cPrime and he is 
based in Vancouver, Canada. Jutta Eckstein is an independent consultant and coach 
based in Germany. She is the author of several books on approaches to scaling Agile 
and using Business Agility practices. Annika Arnholt is a Principal Program Manager 
at Veritas Technologies based in Minnesota, where she is involved in supporting 
NetBackup, a complex product that has 50 Scrum teams working across the globe on 
its development. Nithyanandam Mathiyazhagan (Mathi) is a Lead Program Manager 
for Strategic Services at John Hancock in Boston, where he manages some of their 
digital transformation initiatives. Steven Fraser, the panel impresario, is based in 
California where he advises on tech transfer and open innovation strategies for 
Innoxec. Previously he was the Director of the Cisco Research Center and the Lead for 
HP’s Global University Programs — and he has organized and delivered over 75 
software engineering conferences, panels, and workshops. 
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2 Business Agility Panel Discussion 


Business Agility is the application of Agile practices and the Agile mindset beyond the 
technical community of engineering and IT. The panelists offered two different defi- 
nitions of the core concepts of Business Agility. 

Steve Adolph proposed a definition that is focused on creating a winning business 
strategy: “Be able to learn faster than your competitor.” The practices of Business 
Agility should be directed at helping the business to introduce new products faster and 
respond quickly to changes in the marketplace. Steve says that Business Agility aims to 
“dissolve the artificial barrier between business and IT.” The goal is to get seamless 
interactions across the organization. Business Agility is a competitive strategy to gain 
market share, reduce costs, or improve the product lifecycle. Steve gave several 
examples of companies that were able to compete successfully by reducing the time to 
introduce new products, which allowed them to respond to what their customers wanted. 

Steve emphasized the fact that businesses are competing in an Agile world: “You 
can’t be a fast follower anymore.” If you just try to play catch up to competitors, you 
will fall further and further behind. 

Jutta Eckstein gave a definition that focused on business flexibility in the face of 
disruption. Jutta said that Business Agility is a set of techniques to help a business be 
“more flexible, adaptive, nimble, and responsive — surviving and thriving on disrup- 
tion.” To build an Agile business, the organizational transformation must include 
decentralized decision-making, improved internal feedback, and improved feedback to 
and from the customers [1]. 

Jutta explained that Business Agility doesn’t imply always being ahead of the 
competition. “There are a lot of companies out there who are not ahead of the com- 
petitors, and they are doing really well. Not everyone is first. I wouldn’t take this as a 
mark for being agile, or for Business Agility conformance.” Jutta said that even if a 
company isn’t the fastest or the best, there is still a lot of value to making the business 
more flexible and responsive. 

Both Steve and Jutta agreed that Business Agility is not directly related to the Agile 
Manifesto or Scrum. Some of the standard Agile principles are useful, such as team- 
work and breaking down silos. But Steve warned against using the IT organization to 
“drive” a company-wide Business Agility transformation, especially if they take a 
purely software-centric view of Agility. An agile transformation has to do more than 
merely teach Scrum to a company’s marketing and HR teams. There is a danger that the 
so-called transformation will just be an excuse for the technical folks to tell finance and 
HR how to do their jobs. 

Both of these definitions are useful. By focusing on competition, Steve’s definition 
is easier to justify to business leaders. The focus of this definition is on continuous 
learning and improving — which sends a message to everyone that Business Agility 
transformation is much more than just one day of training. Jutta’s definition is useful 
because it explains some of the key principles of Business Agility, and it is a reminder 
that centralized decision-making, poor communication, and weak feedback are the 
trademarks of the old traditional stovepipe organizations. 

One questioner asked the key question early in the panel discussion: “Is Business 
Agility a solution looking for a problem? Should the Agile community be learning 
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from business, rather than the other way around?” Another audience member had a 
cynical response to the trend towards Business Agility. He claimed that it was mostly a 
way for Agile experts to sell more tools and consultancy work. 

Jutta defended the Business Agility trend, explaining that Business Agility is a 
reaction to the faster pace of business. “There is a need for becoming faster, more 
flexible, and more responsive... I think that is what Business Agility does.” She agreed 
that we need to listen other people. “Is it us teaching HR or finance? I don’t think it is. 
However, they see need for Agility as well, and Business Agility is kind of based on 
the success we’re having with Agile.” Jutta explained that we can learn from other 
companies and other fields: “It would be arrogant to say we know it all.” 

Steve noted that Business Agility is needed because IT is a fundamental constraint 
for many companies to introduce new products and business processes. Business 
Agility’s goal is to meet real business needs, to make sure that “IT is no longer the 
constraint on business to compete.” 

Annika Arnholt pointed out that there are some companies that don’t really need to 
think about Business Agility. On the other hand, she found that in many tech-related 
companies, Business Agility can build bridges. She has observed that an increased 
focus on Agile development in engineering and IT will increase the divide between the 
technical teams and other business organizations — and Business Agility might help 
restore the relationship. She explained that a company should want to have everyone 
rowing in the same direction. 

One questioner was troubled by the chaos he has seen among the leaders many 
companies. “When I walk into an organization and meet the CEOs and CFOs, they 
often have conflicting interests.” Each organization tries to maximize their bonuses, 
without concern for the business as a whole. The question is: “Where’s the incentive... 
unless we change the mindset at the highest level... to even mention Business Agility?” 

All of the panelists agreed that “changing the mindset” is essential to success with 
Business Agility. But teaching and learning the Agile mindset is a big challenge. The 
discussion about education issues continued throughout the panel session. 

Steve pointed out the revolution that has started in education. The best grade 
schools are less focused on lecture-based learning, and Steve shared a personal story: 
“The school my daughter goes to is quite fundamentally different from the schools I 
went to. The students are learning more collaboratively and there are greater oppor- 
tunities.” Collaborative games like Minecraft encourage young people to solve prob- 
lems together. Steve thinks that “education is a huge frontier for us.” It might be the 
next Agile, especially helping businesses that need continual learning. 

One questioner pointed out that most masters-level business students don’t know or 
don’t care about Business Agility. How can we inculcate the Agile mindset in students? 

Jutta pointed out that if we want to affect the mindset, we should focus on teaching 
behaviors: “I always struggle with the belief that we can teach mindset or change 
mindset. What I believe is that we can change behavior, and behavior changes will 
change our habits, and then a new mindset emerges.” The mindset change is the 
product of getting people to change their habits — to change how they work. 

Mathi had some constructive advice for new staff members who are entering 
companies to start their career: 


152 D. Mancl and S. D. Fraser 


e Try to integrate into the organization (“fake it until you make it”). 

e When you see that change is needed, work to create a strong peer network. This kind 
of social support can create consensus to change the way things are being done. 

e Include feedback in the process: come up with your own targets, metrics that help 
you “define your own success.” 


Mathi emphasized the idea that learning in the business context may come from 
different directions: “Our mission is to learn, and learning comes in various shapes. We 
might learn from the competition. Also, fresh voices coming into the organization 
could be a source of learning.” 

The panelists pointed to the value of decentralized decision-making to support 
Business Agility. Annika talked about decentralization as a fundamental idea in 
Business Agility. Teams need to be empowered to make decisions themselves. Jutta 
thought that when leadership tries to centralize decisions, it can be an indicator that the 
company’s leadership doesn’t understand the need for Business Agility. It can also 
make the organization way too slow. Jutta explained that an ideal Agile organization 
would “use the innovative potential of every employee, without waiting for a think tank 
or design thinking session because this will be too slow.” 

The panel was asked about the Agility (or lack of Agility) in the design of products. 
The questioner complained that many products become way too complicated over time 
— a company responds to customer requests by adding new functionality, but they never 
take anything away or rethink the tangled structure. 

Mathi agreed with the questioner. Rather than adding features endlessly, Mathi 
advocated simplifying a product so it can be better understood by a direct consumer. 
“Simplicity is the name of the game, not adding more things on top of what is already 
there.” Steve explained that many companies have complex products because they have 
a design culture that is obsessed with overengineering, because they believe that 
“digital is best.” Every product seems to be loaded up with many unnecessary digital 
features. Business Agility should include the concept of keeping the products simple. 

A final question addressed Business Agility for non-profit organizations. “We have 
been working on Business Agility with civic councils, charities, and universities, not in 
the commercial world. A charity is not trying to be ahead of business or competition, it 
is just trying to survive and do the right thing or positive things in the world.” 

Jutta agreed that competition and profit may not be an organization’s primary goal. 
A company, government, or non-profit may be interested in other issues, such as 
sustainability. “Maybe a company will only stay in business if it looks after the 
environment and is seen by the public as environmentally friendly.” 

Annika was concerned about potential negative effects of always talking about 
“competition” when introducing Business Agility. “I hear people say they are 
uncomfortable with the competitive mindset.” She accepted that we need to think about 
our competitors, but a primary focus (and measurement of success) that concentrates on 
“crushing” the competition may be unhealthy and promote behaviors that are incon- 
sistent with an Agile mindset. Our primary focus should be on what is right for the 
customer and our organization. 

In their concluding comments, the panelists supported the goals of Business Agi- 
lity. Jutta claimed that Business Agility is “beyond Agile — it is about having a holistic 
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view on the company,” but the teams need to buy into the purpose of Business Agility. 
Annika explained the importance of cross-team collaboration — that the teams need to 
see themselves as “not one big warship but a fleet of speedboats, all rowing in the same 
direction.” Mathi thought that Business Agility must “span into corporate social 
responsibility and into the entire business ecosystem.” Steve emphasized the impor- 
tance of learning: “We’re going to have to rename this conference from XP to XL — for 
Extreme Learning.” 


3 Summary 


Business Agility is a set of business practices that go beyond introducing Agility into 
software development. An Agile business organizes itself to introduce new products 
faster and respond quickly to changes in the marketplace. The business decentralizes 
decision-making, improves communication, and improves internal feedback and 
feedback from customers. If decision-making is still centralized and there is weak 
communication and feedback across the enterprise, then the business is going to be too 
slow to react to change. 

All of the panelists warned that Business Agility is not directly related to the Agile 
Manifesto or Scrum. One way it may fail is if technical folks assume Business Agility 
gives them the authority to tell finance and HR how to do their jobs. 

Teaching and learning the Agile mindset is not easy — and the panel believed that a 
new mindset emerges from changes in behavior and habits. There are multiple sources 
of learning: learning from coworkers, learning from the competition, and learning from 
fresh voices coming into the organization. Business Agility will continue to evolve, but 
it is not a destination or a checkbox. 
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Abstract. A panel of university staff and industry Agile experts were invited to 
conclude the XP 2019 conference with a discussion of the conference theme: 
“Agile — the Next 20 Years: Share and Discover!” The panelists gave their views 
of the value of the Agile Manifesto, the possible future of Agile scaling 
frameworks, and some ideas for improving industry-university collaboration. 
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1 The Next 20 Years in Agile 


The first XP conference was held in 2000 in Cagliari, Italy — and that conference 
attracted many software practitioners who were excited about lightweight and iterative 
development methods like Extreme Programming. Today, at the twentieth XP con- 
ference, there is still a lot of interest and excitement about Agile among practitioners 
and researchers. Twenty years from now, will there still be the same level of enthu- 
siasm for Agile software development? Maybe everything will be called Agile. Maybe 
all large software product development projects will use a single standard Agile scaling 
framework similar to one of the approaches being used today. Or maybe today’s Agile 
practices will have evolved into new and better development methods. 

The members of the panel came from all corners of the world and all parts of the 
Agile community. Deepti Jain is an Agile practitioner and coach, and she is the founder 
of AgileVirgin, based in India. Nils Brede Moe is a research manager at SINTEF in 
Norway and a researcher at Blekinge Institute of Technology. Helen Sharp is a pro- 
fessor at The Open University in the United Kingdom, and her research interests 
include human and social aspects of software development. Ken Power is an inde- 
pendent consultant based in Ireland. Philippe Kruchten is a professor of software 
engineering at the University of British Columbia, in Vancouver, Canada. Steven 
Fraser, the panel impresario, is based in California where he advises on tech transfer 
and open innovation strategies for Innoxec. Previously he was the Director of the Cisco 
Research Center and the Lead for HP’s Global University Programs — and he has 
organized and delivered over 75 software engineering conferences, panels, and 
workshops. Philippe and Steve served as the Program Co-chairs for XP 2019. 
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The majority of the panelists agreed that Agile will be around 20 years from now, 
in some form: 


e Helen Sharp: “Agile will be around for quite a while to come yet. In 20 years, we 
may not be calling it that, but it will still be here.” 

e Deepti Jain: “I think that in 20 years, we will be working more independently. We 
will look forward to creating something that works best for us.” 

e Nils Brede Moe: “I have been doing research in Agile for the last 15 years. I’ve seen 
many different companies and many different cultures. It’s being practiced differ- 
ently, and I think for the next 20 years, it will still be practiced differently.” 

e Ken Power: “In terms of the next 20 years — I have no idea... I’m optimistic we will 
see a lot of interesting things in the next 20 years.” 

e Philippe Kruchten: “Agile is there forever. It’s not going to be replaced. Maybe the 
adjective ‘Agile’ will diminish a little bit. But the mindset behind Agile, which is to 
constantly observe your environment and react or respond to it as fast as possible, 
that’s going to be there forever.” 


2 The Next 20 Years Panel Discussion 


At the end of a long and exhausting week, this panel still had the energy to discuss 
many interesting topics. Most of them agreed that Agile will be around in some form 
20 years from now, but it might have a different name in the future. The panelists 
explained that the Agile Manifesto will have diminishing value to the Agile community 
over time. The panelists offered their opinions about the future of Agile scaling 
frameworks and related tools. They complained that the frameworks add too much 
complexity, and they also limit the ability of teams to tailor their way of working. 
Another important discussion was about how to increase the collaboration and com- 
munication between researchers and practitioners. 

In their introductions, the panelists each presented their favorite issues relating to 
Agile methods in the future. Deepti Jain explained that 20 years from now, developers 
will be working more independently. Some of the current Agile frameworks will be too 
constraining: “Many folks will not want to be attached to an organization, or a 
framework or a structure.” Nils Brede Moe believed that there will be many useful 
applications for today’s research work on autonomous teams. But Nils saw technology 
transfer as a major issue: “As researchers, we need to be better at bridging research and 
practice.” Helen Sharp was sure that there is a future for Agile methods: “Agile was 
here before we called it Agile. And Agile will be here 20 years from now whether we 
call it agile or we call it something else.” Ken Power complained that he has no idea 
where things will be in 20 years, but he had advice for the near future. He claimed that 
the real innovators in Agile work will not waste their time arguing about labels. They 
will be exploring the interactions of Agile with other computing technologies: maybe 
flow-based development, maybe artificial intelligence and machine learning. 

Philippe Kruchten injected a bit of humor into his introduction — but his serious 
point was that there will be a swinging pendulum of support for Agile. In the short 
term, he thought that the likeliest reaction to Agile will be popular obsession in the 
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practitioner community. (“All business functions will become Agile: Agile accounting, 
Agile marketing, Agile kindergarten. SAFe becomes an ISO standard, Scrum is taught 
in grade 3.”) But in 10 years or so, this obsession may be followed by a revolution 
rejecting Agile. 

Philippe also offered a list of interesting technology work in Agile, enough to keep 
researchers busy for 20 years. We have to learn to avoid a “one size fits all” process. 
We think we know what coordination, communication, and collaboration are — “but 
when you dig a little bit, you realize it is extremely different across the spectrum of the 
field into which we apply Agile.” We need to learn more about project governance and 
the concept of value. 

There was a question about the future of the Agile Manifesto. “Is it a document that 
gets revered and a religion emerges around it? Or is it sent to the dustbin of history?” 
Helen asked “Shouldn’t it evolve? Shouldn’t it be Agile and be changed as time goes 
on?” Steve Fraser, the panel impresario, recalled the conclusions of the Agile Mani- 
festo panel from earlier in the week. That panel had agreed that the Manifesto is not 
going to be changed. There had been a discussion about the origins of Agile and the 
significance of the Manifesto: “There was the observation that Agile existed before the 
Manifesto. But the Manifesto was seen as a defining moment, and it did both good and 
perhaps had some negative influence on the culture of the community.” Philippe looked 
to the future: “I think the Manifesto has served its purpose. We should stop referring to 
it. We know the flaws that it contains, and we should just move on. You cannot define 
that your organization is Agile by compliance with the Manifesto.” 

Helen and Philippe were skeptical about claims that we will have robots doing all 
of the coding work in the next 20 years. Helen pointed to similar forecasts made 35 
years ago, when “expert systems” were supposed to put programmers out of work. She 
thinks that “software development will change, but I don’t think it will change in that 
way... I don’t think it’s going to be automatic.” Philippe explained that AI and 
Machine Learning may bring some new tools to support programmers, such as tools to 
help them navigate large and complex code bases. But automated tools won’t be able to 
create new designs. “The real decisions about design, I don’t think they can be 
automated.” 

Ken also hoped for technology to give us better programming tools. “The bottle- 
neck in software development is not the interface between the developer and the 
keyboard and the computer. The bottleneck, especially as systems get larger, is learning 
and creating shared understanding. I think we’ll see a lot of innovation improving 
learning and tools to help with shared understanding. I think that’s where the inno- 
vation will be over the next 20 years.” 

One questioner (Maria Paasivaara from IT-University Copenhagen and XP 2020 
General Chair) asked about Agile scaling frameworks: “What is the future regarding 
scaling frameworks? Are we going to have all companies using some of the scaling 
frameworks? Or will they disappear?” 

At the beginning of the XP 2019 conference, Scott Ambler had delivered a 
provocative keynote talk titled “#NoFrameworks: How We Can Take Agile Back!” [1]. 
In that talk, Scott explained that Agile teams should be allowed to choose their own 
way of working. But the current Agile scaling frameworks are simplistic solutions, 
promising great results after a few days of certification training. 
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Helen offered one benefit of Agile scaling frameworks: they help individuals 
structure their work. “The thing about frameworks is that they help you understand 
what kinds of things need to be done, and it gives you vocabulary and context that 
allow people to work.” But she pointed out that there is a danger of trying to solve all 
problems with the same cookie cutter. 

Nils didn’t like the extra complexity that results from using the scaling frameworks. 
“You will see the frameworks for long time, because many people are making a lot of 
money out of them. But some people will raise questions. The frameworks are making 
things more complicated and more complex.” We need to make companies and projects 
less complex in the future to handle external complexity. Instead of simple jobs in 
complex organizations we need complex jobs in simple organizations. Nils thought that 
how to “scale up” Agile development is the wrong question: “People are asking how to 
scale, while research shows that companies are making things more and more complex, 
so the question for the future may be how to scale things down.” 

Deepti added that “it’s about systems thinking.” She said that it can take genera- 
tions to make a shift in how we think. She also explained that companies are reluctant 
to build their own framework. It is hard to spend the time to explore, unlearn, and 
relearn. “No one has time or energy for that. So they will go for the framework from the 
external expert or consultant.” 

Philippe thinks that the frameworks will fade away. He recalled the object oriented 
wars in the 1990s, which was a competition between several major object oriented design 
methods that each had its own standard diagrams. (Philippe paused and added: “I still 
miss the little clouds of the Booch notation.”) But although today’s generation of soft- 
ware developers uses popular object oriented languages like Java and Python, they don’t 
use the diagrams. The same thing may happen to Agile scaling frameworks. “I think at 
some point in time, after some battles, some conferences, and a competition to be the first 
one to be an ISO standard, they will disappear, perhaps about 15 years from now.” 

Other questioners explored the future opportunities for collaboration between 
companies and universities. “This conference has been a meeting place between prac- 
titioners and researchers. If you are a company seeking advice on development methods, 
you get most of the advice from practitioners or consulting companies. In the next 20 
years, do you see anything researchers can do to get involved more involved in practice?” 

Philippe explained that improving access to research publications can be a big 
help. He noted that the XP conference has started publishing its proceedings as Open 
Access. “Most independent developers, like my son here in Montreal, don’t have 
access to IEEE Xplore and ACM Digital Library.” (An individual subscription to ACM 
Digital Library or IEEE Xplore is relatively expensive.) Philippe also thought that 
consortia — groups of software companies who team up with academia — are a good 
forum to increase the interactions between researchers and practitioners. He praised the 
Scandinavian governments who have provided funding for long-term consortia. 

Ken addressed this question from the practitioner viewpoint: “We practitioners 
have a responsibility to innovate and disseminate the results of our industry innovation 
through various channels.” But he challenged university researchers to do a better job 
of collaboration with industry: “There is an opportunity to treat practitioners not as 
research subjects but as research partners — to engage more in a partnership model. Co- 
author papers, co-lead studies — Agile research has a lot of promise for industry- 
academic collaboration.” 
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Nils agreed that collaborative work is good, but we may need to change the way we 
publish research work to make it more useful to practitioners. “Maybe we need to 
change the way we communicate our results — in a way that make more sense for 
practitioners, so we can have a better dialog between researchers and practitioners. 
Unfortunately, researchers just talk to researchers and practitioners to practitioners.” 
Philippe liked the idea and added his own suggestions: “Maybe we need also other 
kinds of publications than the relatively rigid style that we use in Journal of Systems 
and Software and Springer-Verlag journals. The industry people would like to read 
what we write, but maybe we need to make things a little bit more approachable. We 
could have the rigorous things, with all the evidence, research questions, and threat to 
validity, and then we write another simplified version with a little more guidance for 
the practitioners to work with and give us feedback.” 


3 Summary 


The panel members’ crystal balls might be a bit cloudy, but they are mostly optimistic 
about the future of Agile. Agile will be around in some form 20 years from now, 
although it may have a different name, but software development organizations will 
still need strong team collaboration and the ability to respond to change. It is unlikely 
that AI and Machine Learning will replace programmers, but new AJI-based pro- 
gramming tools would be welcome. The demand for Agile scaling frameworks will 
grow for a while, but they will probably fade away over time. Researchers and prac- 
titioners will still need to communicate and share ideas: experimental results, empirical 
studies, new ideas for Agile practices, and new ways of teaching and learning about the 
Agile mindset. 


Reference 


1. Ambler, S.: #NoFrameworks: How We Can Take Agile Back (2019). http://disciplinedagil 
edelivery.com/noframeworks-xp2019/. Accessed 20 June 2019 


Open Access This chapter is licensed under the terms of the Creative Commons Attribution 4.0 
International License (http://creativecommons.org/licenses/by/4.0/), which permits use, sharing, 
adaptation, distribution and reproduction in any medium or format, as long as you give appro- 
priate credit to the original author(s) and the source, provide a link to the Creative Commons 
license and indicate if changes were made. 

The images or other third party material in this chapter are included in the chapter’s Creative 
Commons license, unless indicated otherwise in a credit line to the material. If material is not 
included in the chapter’s Creative Commons license and your intended use is not permitted by 
statutory regulation or exceeds the permitted use, you will need to obtain permission directly 
from the copyright holder. 


Barroca, Leonor 3 
Bass, Julian M. 20, 75 
Berntzen, Marthe 37, 123 


Diebold, Philipp 88 
Dingsgyr, Torgeir 3 


Fagerholm, Fabian 97 


Fraser, Steven D. 137, 143, 149, 154 


Gustavsson, Tomas 29, 105 


Heinecke, Christoph 46 
Hoda, Rashina 13 
Hukkelberg, Ivar 37 
Kettunen, Petri 81, 97 


Laanti, Maarit 81, 97 


Mancl, Dennis 137, 143, 149, 154 


Männistö, Tomi 97 


Author Index 


Marnewick, Carl 64 
Martini, Antonio 112 
Mikalsen, Marius 3, 55 
Mikkonen, Tommi 97 
Moe, Nils Brede 13, 112 


Neesje, Magne 55 


Petit, Yvan 64 


Reime, Erik André 55 


Salameh, Abdallah 20 
Schmitt, Anna 88 
Solem, Anniken 55 
Spiegler, Simone V. 46 
Stray, Viktoria 13, 112 


Theobald, Sven 88 


Wagner, Stefan 46 


